Slow lmtpd

[Andrew Morgan]

On Fri, 2 Mar 2007, Andre Nathan wrote:

> On Fri, 2007-03-02 at 09:21 -0300, Andre Nathan wrote:
>> Is there a cyrus version where specifying "duplicatesuppression: 0"
>> actually prevents the duplicate check and thus the database locking
>> issues I could upgrade to a newer version too, no problem.
>
> I did that, and the lock contention problem with deliver.db is gone. I'm
> still seeing the problem in some users' cyrus.header files though.
> Searching the archives, I found some threads regarding this issue [1,2],
> or more recently in [3]. From the discussion on these threads it seems
> that the lock problem actually is happening with the quota files. The
> first two threads are old (from 2003), and they mention a bug filed in
> bugzilla which is marked as fixed, but the situation I'm seeing, and the
> one on the third thread (from 2006) seems to be the same problem.
>
> Has anyone ever been through that? I have no idea what could be causing
> the lock contention only for some users, so I'm not sure of any
> workaround for the problem :/
>
> [1]http://marc.theaimsgroup.com/?l=info-cyrus&m=106434064805178&w=2
> [2]http://marc.theaimsgroup.com/?l=info-cyrus&m=106434491911478&w=2
> [3]http://www.irbs.net/internet/info-cyrus/0610/0390.html

Items [1,2] are me...   :)

The problems I was having went away when I upgraded Cyrus.  I can't 
remember specifically which version it was fixed in, but you shouldn't be 
running anything older than v2.2.13 these days anyways.

In my case, I had an imaps process that was stuck waiting for input from 
the network for a client that had long since disconnected.  The imaps 
process had a write lock open on the user's quota file, therefore any 
incoming mail for that user was stuck waiting for the write lock to become 
available.

I doubt this is the problem you are seeing.  It sounds to me like you may 
be hitting the limits of your storage system.  I would be fascinated to 
see the output of the command "iostat -x sdb 5" (where 'sdb' is the device 
you have cyrus on) on your system.  Even if you aren't saturating your 
Gigabit Ethernet link to the ATA-over-Ethernet storage, you may be 
exceeding the number I/O operations per second.

Here is an example of the iostat output on one of my cyrus systems:

---------------------------------------------------------
avg-cpu:  %user   %nice    %sys %iowait   %idle
            0.75    0.00    0.35    1.11   97.79

Device:    rrqm/s wrqm/s   r/s   w/s  rsec/s  wsec/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sdb          0.20  91.11 13.13 107.68  195.56 1587.07    97.78   793.54    14.76     0.30    2.50   1.34  16.16
---------------------------------------------------------

This is one of two murder backends running v2.2.13.  The server is a Dell 
2850 with two 3.0GHz Xeons and 2GB of RAM.  It is attached to an EMC Cx500 
SAN, specifically a 7 disk RAID5 array of 10k 146GB Fibre-channel drives.


You can view the load average and process counts for these servers at:

  https://secure.onid.oregonstate.edu/cacti/graph_view.php?action=tree&tree_id=4


 	Andy