[Dovecot] Connection queue full on 2.0.8
Hi,
I can't find any references to this problem on 2.x. I upgraded to 2.0.8 last night, and now I am getting these errors in the logs (along with the server refusing new connections):
Dec 8 09:46:52 orford dovecot: imap-login: Disconnected: Connection queue full (no auth attempts): rip=x.x.x.x, lip=x.x.x.x, TLS Dec 8 09:47:16 orford dovecot: imap-login: Disconnected: Connection queue full (no auth attempts): rip=x.x.x.x, lip=x.x.x.x, TLS handshaking
I have unsuccessfully tried to tweak my settings to prevent this problem, and any help would be appreciated. The server has plenty of power for increasing process limits, etc.
Below is the output of "dovecot -n". We have users with some _very_ large mailboxes (~400 000 messages) so some of the limits might appear excessive.:
# 2.0.8: /etc/dovecot/dovecot.conf # OS: Linux 2.6.35-gentoo-r5+ x86_64 Gentoo Base System release 2.0.1 auth_cache_size = 10 M auth_mechanisms = plain login auth_worker_max_count = 80 default_client_limit = 2048 default_process_limit = 256 default_vsz_limit = 512 M first_valid_uid = 125 last_valid_uid = 20000 listen = 127.0.0.1 x.x.x.x login_greeting = IMAP ready. mail_location = maildir:~/Maildir managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date mdbox_rotate_size = 10 M namespace { hidden = no inbox = yes list = yes location = prefix = subscriptions = yes type = private } namespace { hidden = yes list = no location = prefix = INBOX. subscriptions = yes type = private } namespace { hidden = no list = yes location = maildir:/home/shared/Maildir:CONTROL=~/Maildir/control/shared:INDEX=~/Maildir/index/shared prefix = shared. subscriptions = no type = public } passdb { args = failure_show_msg=yes driver = pam } plugin { quota = fs:User quota:user quota_warning2 = storage=80%% quota-warning 80 %u sieve = ~/dovecot.sieve sieve_dir = ~/sieve } protocols = imap pop3 service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0666 user = postfix } } service imap-login { process_min_avail = 5 } service imap { process_limit = 2048 } service managesieve-login { inet_listener sieve_deprecated { port = 2000 } } service pop3 { process_limit = 128 } ssl_cert =
On 8.12.2010, at 15.10, Patrick McLean wrote:
Dec 8 09:46:52 orford dovecot: imap-login: Disconnected: Connection queue full (no auth attempts): rip=x.x.x.x, lip=x.x.x.x, TLS .. service imap-login { process_min_avail = 5 }
You reached the default limits of imap-login processes. You probably want to switch to high performance mode for them: http://wiki2.dovecot.org/LoginProcess
On Wed, Dec 08, 2010 at 08:42:42PM +0000, Timo Sirainen wrote:
You reached the default limits of imap-login processes. You probably want to switch to high performance mode for them: http://wiki2.dovecot.org/LoginProcess
I want to switch to that mode too. The doc says :
"vsz_limit should be increased to avoid out of memory errors, especially if you're using SSL/TLS."
Is there a way/rule of thumb to guess the appropriate value ?
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
On 14.12.2010, at 17.12, Thomas Hummel wrote:
You reached the default limits of imap-login processes. You probably want to switch to high performance mode for them: http://wiki2.dovecot.org/LoginProcess
I want to switch to that mode too. The doc says :
"vsz_limit should be increased to avoid out of memory errors, especially if you're using SSL/TLS."
Is there a way/rule of thumb to guess the appropriate value ?
No idea :) vsz_limit=0 will at least always work, with the possibility of a memory leak eating all your memory. Maybe set it to 1 GB or so. It's anyway better to set it too high than too low to avoid killing existing connections when vsz_limit is exceeded.
On Tue, Dec 14, 2010 at 07:45:58PM +0000, Timo Sirainen wrote:
Is there a way/rule of thumb to guess the appropriate value ?
No idea :) vsz_limit=0 will at least always work, with the possibility of a memory leak eating all your memory. Maybe set it to 1 GB or so. It's anyway better to set it too high than too low to avoid killing existing connections when vsz_limit is exceeded.
Just to be sure : what is that vsz_limit exactly to begin with ?
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
On 14.12.2010, at 21.38, Thomas Hummel wrote:
On Tue, Dec 14, 2010 at 07:45:58PM +0000, Timo Sirainen wrote:
Is there a way/rule of thumb to guess the appropriate value ?
No idea :) vsz_limit=0 will at least always work, with the possibility of a memory leak eating all your memory. Maybe set it to 1 GB or so. It's anyway better to set it too high than too low to avoid killing existing connections when vsz_limit is exceeded.
Just to be sure : what is that vsz_limit exactly to begin with ?
It's used to set RLIMIT_DATA, and also RLIMIT_AS in operating systems that support that, with setrlimit() call. http://linux.die.net/man/2/setrlimit
Basically kernel enforces that the process won't be using too much memory.
On Wed, Dec 08, 2010 at 08:42:42PM +0000, Timo Sirainen wrote:
You reached the default limits of imap-login processes. You probably want to switch to high performance mode for them: http://wiki2.dovecot.org/LoginProcess
By the way,
what does count for one "client" in the "client_limit" setting ? For instance, if a client (User Agent like Thunderbird) is configured to open 5 connections, does that increase the client count by 5 for this limit ?
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
On Wed, 2010-12-15 at 17:07 +0100, Thomas Hummel wrote:
On Wed, Dec 08, 2010 at 08:42:42PM +0000, Timo Sirainen wrote:
You reached the default limits of imap-login processes. You probably want to switch to high performance mode for them: http://wiki2.dovecot.org/LoginProcess
By the way,
what does count for one "client" in the "client_limit" setting ? For instance, if a client (User Agent like Thunderbird) is configured to open 5 connections, does that increase the client count by 5 for this limit ?
Depends.. One client is one unix/tcp connection for that specific service process. Then it depends on the service's settings:
If service imap-login has been configured with service_count=0, it also triggers client_limit=$default_client_limit. Then you can have that many simultaneous connections to that process. But imap-login processes stop handling connections after user has logged in, except if the connection was using SSL/TLS.
imap processes then typically have client_limit=1 and instead the process count increases.
So with Thunderbird that creates 5 SSL connections you'll get:
- 5 less clients available for imap-login service
- 5 less processes available for imap service
participants (3)
-
Patrick McLean
-
Thomas Hummel
-
Timo Sirainen