[Dovecot] 0.99.10.x auth memory leak?

[Christian Balzer]

Timo wrote:

>On 22.7.2004, at 06:01, Christian Balzer wrote:
>
>>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>> 31235 root      16   0  220m 216m 5560 S  0.0 10.7  25:01.54 
>> dovecot-auth
>> 31234 root      16   0  205m 202m 5560 S  0.0 10.0  24:08.84 
>> dovecot-auth
>> 31231 root      16   0  200m 196m 5560 S  0.7  9.7  23:25.37 
>> dovecot-auth
>> 31232 root      16   0  196m 192m 5560 S  0.0  9.5  23:10.44 
>> dovecot-auth
>> 31233 root      15   0  179m 175m 5560 S  0.3  8.6  22:13.07 
>> dovecot-auth
>> ---
>>
>> So, I guess my questions to Timo are:
>>
>> Think it's leaky and any idea where?
>
>I didn't see any obvious leaks in the code. 1.0-test's dovecot-auth can 
>be easily run standalon, so it's easier to check for leaks with it. 
>I'll try to setup LDAP server and see if I can find any.
>
Indeed, this is of course running against a LDAP server.

>How soon does the memory go that high up? 
It seems to grow gradually, a visible but not dramatic growth over time.
This was after about 2 weeks of non-stop operation.

>Do you restart the processes manually? 
I did today, the last time was due to the update to .6. After about
10 hours they have now grown by roughly 6MB respectively...

>Do they stay in around 200MB by themselves, or only because 
>max. auth process size is 256MB (by default) and they restart 
>themselves when they reach it (log should have "out of memory" errors)?
>
Did not run them long enough to run into that barrier, but they were 
still growing, so most likely this would have happened eventually.
And I'm "afraid" (read: eagerly awaiting it's arrival :) that the .7 
Debian package will arrive in Woody before they have grown to that size 
again. ;)

>> Given the load, would a single auth process be a bad idea?
>> (it is a quite fast dual opteron box)
>
>In that process list they were taking less than 1% CPU, so reducing 
>them shouldn't make it slower. But I'd still leave two just in case one 
>of them gets stuck for some reason.
>
Well, this would be just a work-around anyway. So for the time being 
I'll leave things as they are in the hopes that by the next time 
things grow that large a real solution has surfaced. :)

Regards,

Christian Balzer
-- 
Christian Balzer        Network/Systems Engineer                NOC
chibi at gol.com   	Global OnLine Japan/Fusion Network Services
http://www.gol.com/