- Previous message: John Capo: "Re: Slow lmtpd"
- Maybe in reply to: (no name): "Re: Slow lmtpd"
- Next in thread: Andre Nathan: "Re: Slow lmtpd"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
|
|
|
From: Andrew Morgan (no email)
Date: Fri Mar 02 2007 - 20:07:28 EST
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
---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
|
|
|