[Dovecot] Leaky dovecot-auth ?
chibi at gol.com
Thu Jun 21 10:49:39 EEST 2007
On Tue, 19 Jun 2007 14:39:59 +0300 Timo Sirainen <tss at iki.fi> wrote:
> On Tue, 2007-06-19 at 13:40 +0900, Christian Balzer wrote:
> > 1. How and why would the memory footprint of dovecot-auth grow when
> > there is no change in the amount of users in the DB?
> The only thing that's changing the size of dovecot-auth is how many
> requests it's simultaneously handling. For example if you try to login
> with invalid user/pass 1000 times within a second, dovecot-auth keeps
> those 1000 requests in memory for a couple of seconds until it returns
> with failure. But this happens also with normal requests, just not for
> so long.
There is nowhere near anything of this kind of concurrency and
memory should be returned after a while, but that is clearly not
happening. The dovecot-auth is now at 200/160MB and thus prone to
blow up over the weekend I guess.
> You could try http://dovecot.org/patches/debug/mempool-accounting.diff
> and send USR1 signal to dovecot-auth after a while. It logs how much
> memory is used by all existing memory pools. Each auth request has its
> own pool, so if it's really leaking them it's probably logging a lot of
> lines. If not, then the leak is elsewhere.
I grabbed the Debian package source on a test machine (not gonna chance
anything on the production servers), applied the patch, did add
--enable-debug to the debian/rules file (and got the #define DEBUG
in config.h), created the binary packages, installed, configured,
started them, tested a few logins and... nothing gets logged
in mail.* if I send a USR1 to dovecot-auth. Anything I'm missing?
But no matter, it is clearly leaking just as bad as 0.99 and I venture
that his is the largest installation with LDAP as authentication backend.
I wonder if this leak would be avoided by having LDAP lookups performed
by worker processes as with SQL.
> > 2. What will happen when the single dovecot-auth process reaches 256MB
> > in the end? Internal housekeeping attempts of that process? A whack to
> > the head from the master process like in 0.99 and thus more erroneous
> > authentication failures, potentially aggravated by the fact that there
> > is just single dovecot-auth process?
> The same as 0.99. You could also kill -HUP dovecot when dovecot-auth is
> nearing the limit. That makes it a bit nicer, although not perfectly
> safe either (should fix this some day..).
If that leak can't be found I would very much appreciate a solution that
at least avoids failed and/or delayed logins.
Christian Balzer Network/Systems Engineer NOC
chibi at gol.com Global OnLine Japan/Fusion Network Services
More information about the dovecot