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@gol.com Global OnLine Japan/Fusion Network Services http://www.gol.com/