[Dovecot] load increase after upgrade to 2.0.8

[Mark Moseley]

On Wed, Dec 8, 2010 at 11:54 PM, Ralf Hildebrandt
<Ralf.Hildebrandt at charite.de> wrote:
> * Mark Moseley <moseleymark at gmail.com>:
>> On Wed, Dec 8, 2010 at 3:03 PM, Timo Sirainen <tss at 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).