On Thu, 2009-03-19 at 14:01 +0000, Mike Brudenell wrote:
When I upgraded from 1.0.15 I had 1.1.11 telling me off for having the fd limit set too low at 2048 when I started Dovecot. Instead it told me to raise the limit to at least 10128, so I did. Hence I was a bit surprised to find the limit lowered down to 533 if it had told me it wanted the higher number.
It's the "dovecot" process that has trouble with the fd limits, because it needs one fd for each child process (for logging).
login_processes_count should be about the same as the number of CPUs/cores on the system (maybe +1).
We're running a pair of servers, each with 8 CPUs. So I'm guessing my
login_processes_count = 10
should be OK?
Seems like a good value.
I'm guessing that if I increase login_max_connections from its current 256 to 1024 this might delay the problem occurring?
I was originally thinking that if you used fewer login processes the load would be more balanced between processes and might never reach the max limits then.
And perhaps if I were restart Dovecot in the small hours of the night every few days?
kill -HUP dovecot would be enough.
Or is an alternative workaround to change login_process_per_connection from no to yes?
That would cause you to get thousands of login processes. Probably not a good idea.
...If I were to do this am I right in thinking that imap-login then plays no part in SSL-connected IMAP sessions?
imap-login always proxies SSL connections. Then you'd have one process proxying one SSL connection.