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.
signature.asc
Description: This is a digitally signed message part
