[Dovecot] quick, quick, slow...
Hi,
I'm (still) evaluating dovecot for a switch from UW in the near future. All the following happens on a Solaris server.
Functionally, all is well. However, I see strange phenomena.
Normally, dovecot is pretty swift. Every now and then, though, things slow down to a crawl. Everything seems to be working, still, but a few orders of magnitude slower. A copy of an outgoing message (of a few lines) to my Out box, which normally succeeds nearly instantly, suddenly takes over 30 minutes, for example.
Obvious things to look for would be conflicting locking strategies. As far as I know, though, my mail delivery agent (procmail) and all mail handling software use dotlocking, fcntl lockf, in that order), as does dovecot.
In syslog there's nothing to see, except an occasional
SSL_accept() syscall failed: EOFmesssage, which I can correlate to my service monitoring software (nagios), which checks for the presence of the imaps service.
When this happens and I quit my mail agent (Thunderbird), an imap process seems to remain on the server. Killing that does not resolve the extreme slowdown; that persists on consecitive reruns of my mailer.
I'm at a loss here. Any hints?
On Tue, Aug 30, 2005 at 10:11:38AM +0200, Jeroen Scheerder wrote:
I'm at a loss here. Any hints?
Can you trace the process (with children) for us?
C.
hail eris http://rubberduck.com/
Jeroen Scheerder wrote:
I'm at a loss here. Any hints?
Can you trace the process (with children) for us?
If I knew how, yes. Note, this is a Solaris 7 system; no Dtrace available.
Just remembered about truss'. Dovecot's wiki mentions strace' only (which
does exist, but is a different thing altogether).
Will truss away when the problem is there, and try to get some useful info.
Jeroen Scheerder:
Will truss away when the problem is there, and try to get some useful info.
Tracing does not reveal anyting interesting, yet.
The problem (extreme slowless; dozens of minutes to write a message to a mailbox, or read a message from one) occurs now.
I've trussed the relevant imap process:
poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) (sleeping...) poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 6) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0
[snip a few thousand repetitive lines]
... and so on, and so forth. Another imap process, that polls my inbox, looks very different: I see stat64()'s there, and mmap()/munmap()'s, and reads with stuff that looks convincingly like proper IMAP talk.
The same mailbox that is problematic (apparently) can be accessed just fine using mutt directly, without mutt complaining about existing locks (as it does, when there *are* locks in place).
So this imap process just seems to be idling. Hmm.
Jeroen Scheerder wrote:
Jeroen Scheerder:
Will truss away when the problem is there, and try to get some useful info.
Tracing does not reveal anyting interesting, yet.
I've just raised the maximum number of IMAP connections to use simultaneously in the Thunderbird IMAP client, and this shifts the problem further away. Could it be my mail client stalling because it stupidly doesn't (re)use its existing IMAP connections effectively? Is this perhaps a known Thunderbird issue?
participants (2)
-
Charlie Allom
-
Jeroen Scheerder