On Wed, Dec 8, 2010 at 11:54 PM, Ralf Hildebrandt Ralf.Hildebrandt@charite.de wrote:
- Mark Moseley moseleymark@gmail.com:
On Wed, Dec 8, 2010 at 3:03 PM, Timo Sirainen tss@iki.fi wrote:
On 8.12.2010, at 22.52, Cor Bosman wrote:
1 server with service_count = 0, and src/imap/main.c patch
By this you mean service_count=0 for both service imap-login and service imap blocks, right?
Speaking from my own experience, the system loads on our dovecot boxes went up *substantially* when we upgraded kernels from 2.6.32.x and 2.6.33.x to newer ones (late 2.6.35.x and 2.6.36 -- haven't tried 2.6.36.1 yet). But I also saw loads on all sort of other types of boxes grow when moved to 2.6.35.x and 2.6.36, so it's not necessarily dovecot-related. Though you've got plenty to choose from between 2.6.27.x and up.
We're on 2.6.32 and the load only goes up when I change dovecot (not when I change the kernel, which I didn't do so far)
If you at some point upgrade to >2.6.35, I'd be interested to hear if the load skyrockets on you. I also get the impression that the load average calculation in these recent kernels is 'touchier' than in pre-2.6.35. Even with similar CPU and I/O utilization, the load average on a >2.6.35 both is much higher than pre- and it also seems to react more quickly; more jitter I guess. That's based on nothing scientific though.
Getting 'imap-login' and 'pop3-login' set to service_count=0 and 'pop3' and 'imap' set to service_count=1000 (as per Timo's suggestion) helped keep the boxes from spinning into oblivion. To reduce the enormous amount of context switches, I've got 'pop3's client_limit set to 4. I played around with 'imap's client_limit between 1 and 5 but haven't quite found the sweet spot yet. pop3 with client_limit 4 seems to work pretty good. That brought context switches down from 10,000-30,000 to sub-10,000.
Interesting. Would that spawn a lot of pop3 processes? On the other hand, almost nobody is using pop3 here
Upping the client_limit actually results in less processes, since a single process can service up to #client_limit connections. When I bumped up the client_limit for imap, my context switches plummeted. Though as Timo pointed out on another thread the other day when I was asking about this, when that proc blocks on I/O, it's blocking all the connections that the process is servicing.Timo, correct me if I'm wildly off here -- I didn't even know this existed before a week or two ago. So you can then end up creating a bottleneck, thus why I've been playing with finding a sweet spot for imap. I figure that enough of a process's imap connections must be sitting in IDLE at any given moment, so setting client_limit to like 4 or 5 isn't too bad. Though it's not impossible that by putting multiple connections on a single process, I'm actually throttiling the system, resulting in fewer context switches (though I'd imagine bottlenecked procs would be blocked on I/O and do a lot of volcs's).