On Mon, 02 Jul 2007 17:37:05 +0300 Timo Sirainen tss@iki.fi wrote:
On Mon, 2007-07-02 at 15:20 +0900, Christian Balzer wrote:
Jul 2 14:12:30 engtest03 dovecot: auth(default): pool auth request handler: 104 / 4080 bytes Jul 2 14:12:30 engtest03 last message repeated 128 times
Auth request handler is created for each imap-login connection. So if you have 128 imap-login processes this isn't a leak.
At that point in time only POP3 was tried, since this is by far the most used protocol here and rabid defaults to it anyway. But there were plenty of pop3-login processes indeed. Enough to make up that number combined with the IMAP ones. Which is interesting, as this does NOT happen on the production servers, I guess rabid can dish out even more stress than my users (and cause these login processes to be left hanging around).
But that's not the issue anyway, with identical pool outputs the local DB incarnation retains its size (I got an internal IMAP server with 1.0.0 and PAM and a few dozen intense users which also shows no signs of a growing dovecot-auth) while the LDAP DB one keeps growing with nothing to show for in that pool debug output.
Hmm. Does this help: http://hg.dovecot.org/dovecot-1.0/rev/50c79521e8f5
Will try that tomorrow if I can.
Oh and HUP'ing the master is not an option here, I guess the system load triggers a race condition in dovecot because several times when doing so I got this:
Jun 22 15:08:58 mb11 dovecot: listen(143) failed: Interrupted system call
Did you use killall? I think this happens only with it.
Nope, this is a Debian/Linux show and I did HUP just the master process. It only happened some of the times on the (then) busiest node, but it clearly is a race condition of sorts. Set up a test environment with about 30-50 logins/second and I'm sure you can reproduce it. ;)
Regards,
Christian
Christian Balzer Network/Systems Engineer NOC chibi@gol.com Global OnLine Japan/Fusion Network Services http://www.gol.com/