>>> 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!
