[Dovecot] Imap-login service count/limits
Hello Timo,
I'm trying to configure dovecot-2.1.15 master correctly regarding imap-login limits. I want to use service_count=0 and I'm starting with something like this :
#default_process_limit = 100 #default_client_limit = 1000
service imap-login {
[...]
service_count = 0 process_min_avail = 8 vsz_limit = 1024M
}
-> Does it make sense to set a process_limit if service_count = 0 ? why ? Doesn't service_count = 0 mean that no additionnal imap-login process would be created (except for process_min_avail) ?
-> Does it make sense to set process_min_avail <> 0 if service_count = 0 ? why ? and if yes, what's the rule of thumb to find the correct value according to the number of connections estimation ?
-> Assuming every client is configured to use STARTTLS and opens by default 5 imap connections, each client would consume 5 of the 1000 default_client_limit, right ?
-> is 1024M too high for vsz_limit and may expose to memory leaks ?
In other words, what limit should be raised to scale a lot a connections ?
Thanks
-- Thomas Hummel | Institut Pasteur <hummel@pasteur.fr> | Groupe Exploitation et Infrastructure
On Tue, Feb 26, 2013 at 11:08:18AM +0100, Thomas Hummel wrote:
-> Does it make sense
Sorry, I was unclear. Let me rephrase :
from my understanding of the doc, process_min_avail seems to have a slightly different behavior depending of if service_count is 1 or 0. Is it correct ?
The doc states that process_min_avail in the case of service_count = 1 is used to avoid latency and in the case of service_count = 0 to make sure not only the one imap-login is used (if below the client_limit threshold).
Why would it make no sense to set (service_count=0) process_min_avail > number of cpu ? Because there is no fork/exec of another imap-login latency ?
Besides, why would process_limit be reached since service_count=0 means that this one imap-login process handles an unlimited number of connections ?
Thanks
-- Thomas Hummel | Institut Pasteur <hummel@pasteur.fr> | Groupe Exploitation et Infrastructure
On Tue, Feb 26, 2013 at 02:04:07PM +0100, Thomas Hummel wrote:
Besides, why would [...]
I think I get it, I might have been confused by the term "unlimited" in "the only useful values are 0 (unlimited)" in the sample config file comment.
As I see it now :
- service_count = 0 :
. number of connections is not "unlimited" but limited by client_limit (or default_client_limit) for each imap-login process first and then by process_limit (or default_process_limit)
. since only when client_limit is reached a new imap-login is forked (in the limit of process_limit), pre-forking process_min_avail load-balance the work across all CPUs instead of staying on a single CPU until client_limit is reached.
service_count = 1
. client_limit has no effect since 1 connection <-> 1 process . pre-forking process_min_avail avoid the fork-exec overhead/latency
Is this correct now ?
Thanks
-- Thomas Hummel | Institut Pasteur <hummel@pasteur.fr> | Groupe Exploitation et Infrastructure
participants (1)
-
Thomas Hummel