On 15.11.2010, at 22.58, Mark Moseley wrote: >> Timo, >> Any hints on how many POP3 and IMAP connections I'd be able to get >> away with in a single threads with the above setup, assuming they're >> relative busy?
The problem is that if there is any waiting for locks, all the other connections hang there as well waiting for it. Same for any type of disk I/O waits. I don't really know how many you could get away with.. My official recommendation would be to keep it 1 connection = 1 process, since that's guaranteed to work. >> BTW, I realize process_min_avail is just a minimum, but without having >> service_count=1, what would cause dovecot to fork off more processes >> than #process_min_avail? When all the existing processes have reached client_limit, a new process is created. > emailuser 2625 0.0 0.1 4748 3132 ? S 17:15 0:00 \_ > dovecot/imap [2 connections] .. > emailuser 2632 0.7 2.6 59440 54492 ? S 17:15 0:14 \_ > dovecot/imap [209 connections] > > Is there a way to spread those out more or is there probably no need > to? Whichever process is fastest to grab a new connection gets it. > I imagine in the case of PID 2632, a large number of those > connections are just sitting in IDLE and doing nothing beyond > stat64()'s. Or maybe a better question would be, is there a setting > I'm not finding that puts an upper limit on connections for a single > process, so a single process will stop servicing new connections after > it hits a certain # and lets the other less-loaded processes handle > the new connection. All the various *_limit settings appear to be > across all processes, not per-processs like this. This btw is 2.0.7 > (but with the proctitle patch). service imap { client_limit = 5 }