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.
The activity per cluster node on the 0.99 boxes was about 700k logins (mostly pop3) per day and 5 dovecot-auth processes with a 64MB limit each.
The migrated users so far are of the less active kind and on one node of the 1.0.0 cluster we see about 70k logins/day and currently the dovecot-auth process there is hovering at 123/84MB (VIRT/RES in top). It was at 121/82MB when I checked 4 hours ago and no new users have been added to that node for 2 days. Authentication backend is still LDAP, no caching, 256MB process size limit. There are just 16k users on that node at this point in time, with only 1200 distinct users generating those 70k logins/day.
We will start migrating the rest of the users tomorrow and now I'm wondering:
How and why would the memory footprint of dovecot-auth grow when there is no change in the amount of users in the DB?
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?
I guess at the current rate of leakage we shall know the answers to #2 soon one way or another. ;)
Regards,
Christan
Christian Balzer Network/Systems Engineer NOC chibi@gol.com Global OnLine Japan/Fusion Network Services http://www.gol.com/