On Tue, 2007-06-19 at 13:40 +0900, Christian Balzer wrote: > Hello, > > as mentioned before, we are migrating our mailboxes from a 0.99 cluster > to a 1.0.0 one. With 0.99 dovecot-auth (with LDAP as backend) was leaking > quite happily and the dovecot-auth processes frequently did hit their > size limit and thus were killed and restarted. Which in 0.99 at least > lead to authentication failures on a busy server, as the dovecot > master process just killed off the auth process w/o disabling new > connections to it first and letting any current authentications finish.
It's actually your kernel that kills the process. > 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. 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. > 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..).
signature.asc
Description: This is a digitally signed message part
