- Previous message: David Carter: "Re: single instance store and replication"
- Maybe in reply to: (no name): "Re: Slow lmtpd"
- Next in thread: John Madden: "Re: Slow lmtpd"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
|
|
|
From: Andre Nathan (no email)
Date: Thu Mar 01 2007 - 10:50:11 EST
On Thu, 2007-03-01 at 10:38 -0300, Andre Nathan wrote:
> After postfix sends the ".", it takes lmtpd more than 5 minutes to send
> the "250 2.1.5 Ok" back (everything else on the lmtp conversation
> happens in the same second). Is this the time when lmtpd writes the
> message to disk? I'm trying to find out if I/O is really the bottleneck
> here.
Running strace on the appropriate lmtpd here showed me that the process
was blocked waiting for a write lock all the time:
fcntl64(6, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}
Turns out fd 6 refers to deliver.db:
ls -l /proc/15999/fd/6
lrwx------ 1 cyrus mail 64 Mar 1 11:15 /proc/15999/fd/6
-> /var/lib/imap/deliver.db
I disabled duplicate suppression in imapd.conf for now and the situation
has improved greatly since. Does anyone have this kind of problem with
lock contention in heavily loaded servers? Is there anything that can be
done to tune this, other than disabling the duplicate test?
Thanks,
Andre
---- 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
|
|
|