[Dovecot] Login process connection routing
Timo,
Just out of curiosity, how are incoming connections routed to login processes when run with: service imap-login { service_count = 0 }
I've been playing with this on our test director, and the process connection counts look somewhat unbalanced. I'm wondering if there are any performance issues with having a single process handle so many connections. It seems fine (system load is actually lower than with service_count = 1), but I thought I'd ask.
/usr/sbin/dovecot \_ dovecot/imap-login \_ dovecot/imap-login [1 connections (1 TLS)] \_ dovecot/imap-login \_ dovecot/imap-login [5 connections (5 TLS)] \_ dovecot/imap-login [1 connections (1 TLS)] \_ dovecot/imap-login [4 connections (4 TLS)] \_ dovecot/imap-login [1 connections (1 TLS)] \_ dovecot/imap-login [1 connections (1 TLS)] \_ dovecot/imap-login [315 connections (315 TLS)] \_ dovecot/imap-login [63 connections (63 TLS)] \_ dovecot/imap-login [12 connections (12 TLS)] \_ dovecot/imap-login \_ dovecot/imap-login [10 connections (10 TLS)] \_ dovecot/imap-login [2 connections (2 TLS)] \_ dovecot/imap-login [370 connections (370 TLS)] \_ dovecot/imap-login [24 connections (24 TLS)]
-Brad
On Tue, 2010-07-20 at 09:57 -0700, Brandon Davidson wrote:
Timo,
Just out of curiosity, how are incoming connections routed to login processes when run with: service imap-login { service_count = 0 }
I've been playing with this on our test director, and the process connection counts look somewhat unbalanced. I'm wondering if there are any performance issues with having a single process handle so many connections. It seems fine (system load is actually lower than with service_count = 1), but I thought I'd ask.
Dovecot lets kernel assign it. Whichever process grabs it first, handles it.
/usr/sbin/dovecot \_ dovecot/imap-login \_ dovecot/imap-login [1 connections (1 TLS)] \_ dovecot/imap-login \_ dovecot/imap-login [5 connections (5 TLS)] \_ dovecot/imap-login [1 connections (1 TLS)] \_ dovecot/imap-login [4 connections (4 TLS)] \_ dovecot/imap-login [1 connections (1 TLS)] \_ dovecot/imap-login [1 connections (1 TLS)] \_ dovecot/imap-login [315 connections (315 TLS)] \_ dovecot/imap-login [63 connections (63 TLS)] \_ dovecot/imap-login [12 connections (12 TLS)] \_ dovecot/imap-login \_ dovecot/imap-login [10 connections (10 TLS)] \_ dovecot/imap-login [2 connections (2 TLS)] \_ dovecot/imap-login [370 connections (370 TLS)] \_ dovecot/imap-login [24 connections (24 TLS)]
You probably have too many login processes. process_min_avail should be set to about the same as the number of CPU cores. Since there are two processes handling most of the connections, do you also happen to have 2 cores? :)
Timo,
-----Original Message----- From: Timo Sirainen [mailto:tss@iki.fi]
Dovecot lets kernel assign it. Whichever process grabs it first, handles it.
Makes sense.
You probably have too many login processes. process_min_avail should be set to about the same as the number of CPU cores.
Ahh, OK - that's good guidance, I didn't remember hearing that. I had just left the old setting in place from when we were forking off a process per session, where it made sense as more of a prefork.
Since there are two processes handling most of the connections, do you also happen to have 2 cores? :)
Two cores with HT (looks like four), but yes ;)
Thanks!
-Brad
participants (3)
-
Brad Davidson
-
Brandon Davidson
-
Timo Sirainen