Setting imap-login process_limit when service_count>1

Joseph Tam jtam.home at gmail.com
Thu Mar 24 23:35:55 UTC 2022


More of my users are accessing mail remotely, which probably explained
why I started seeing

 	Mar 18 05:50:34 dovecot: master: Warning: service(imap-login):
 	process_limit (2) reached, client connections are being dropped

I played around with increasing limits, but made the mistake of setting
service_count to a value other than 0 and 1.

 	service imap-login {
 		client_limit = 1024
 		service_count = 10240
 		process_min_avail = 2
 		process_limit = 8
 	}

Doubling and redoubling process_limit and increasing service_count didn't
prevent IMAP from eventually grinding to a halt because process_limit
was reached.

 	Mar 18 12:36:12 dovecot: master: Warning: service(imap-login):
 	process_limit (4) reached, client connections are being dropped

 	Mar 18 20:39:48 viol dovecot: master: Warning: service(imap-login):
 	process_limit (8) reached, client connections are being dropped

Observing the way imap-login processes spawn and retain file descriptors,
I finally understood the subtlety of [1], which explains that imap-login
will not exit despite reaching service_count if one SSL connection is
still open.

With many long-lived client connections, the asymptotic behaviour is that
the total #clients plateaus, but get spread out over many imap-login
processes, with many lingering on to hold a few SSL connections.
For service_count>1, process_limit should be set to a large fraction of
peak simultaneous clients (i.e. the same value used when service_count=1),
otherwise there is a high likelihood of running into process_limit and
game over.

Given this behaviour, there doesn't seem much sense in setting
service_count to anything but 0 (unlimited => performance mode) or 1
(security mode).  Setting to other values supposedly limit memory leaks,
but if a single persistent SSL client can hold up an imap-login process
from exiting and releasing memory, it seems to negate this purpose.

Anyways, maybe [1] can mention this so others don't fall into the same
pit I did.

References
 	[1] https://doc.dovecot.org/admin_manual/login_processes/

Joseph Tam <jtam.home at gmail.com>


More information about the dovecot mailing list