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 }
Yeah, client_limit looks perfect. I'd googled "client_limit" a few times over the past week and for some reason, I thought client_limit was also cumulative across all procs, instead of per-proc. But it's working perfectly now.
I see your point about any blocking operations. I'll start low and work my way up and abandon service_limit=0 completely if I start to get user complaints about it. Right now the possibility of cutting context switches by 80% is just too promising to pass up. With typically 600-700 imap procs and 200-300 pop3 procs, the time spent in kernel scheduling was getting very high and these are only dual core uniprocessor boxes, otherwise it'd be more of a moot point if I had 8+ cores to work with.
Thanks Timo!