[Dovecot] High CPU load
Hello,
I'm using dovecot-1.0.b9 on a FreeBSD 6.1 system. Usually we have 6 clients connected to dovecot through IMAPs. These clients are Thunderbird 1.5 programs. After some hours, one or two processed go up to 100% WCPU. As an example, this is what I see when I run 'top':
last pid: 5111; load averages: 1.34, 1.82, 1.75 up 13+00:04:09
15:26:59
150 processes: 2 running, 147 sleeping, 1 zombie
CPU states: 21.2% user, 0.0% nice, 47.7% system, 0.0% interrupt, 31.1%
idle
Mem: 149M Active, 368M Inact, 196M Wired, 29M Cache, 111M Buf, 255M Free
Swap: 5120M Total, 548M Used, 4572M Free, 10% Inuse
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 52627 thomas 1 109 0 2940K 1500K CPU1 0 21:49 99.02% imap
When there are two rebellious clients, they occupy 50-50% CPU time. If I restart thunderbird, then all goes well for a couple of minutes. I need to solve this problem. I already had a system crash that was probably caused by the cpu heat. Pleas help me.
Laszlo
Hi,
Nagy László wrote:
Hello,
I'm using dovecot-1.0.b9 on a FreeBSD 6.1 system. Usually we have 6 clients connected to dovecot through IMAPs. These clients are Thunderbird 1.5 programs. After some hours, one or two processed go up to 100% WCPU. As an example, this is what I see when I run 'top':
[...]
I've also noticed this (though, using dovecot 1.0.rc7):
http://dovecot.org/list/dovecot/2006-August/015656.html
Unfortunately, I don't known when/why it happens.
-- Rui LopesOn Thu, 2006-08-24 at 21:33 +0200, Nagy László wrote:
Hello,
I'm using dovecot-1.0.b9 on a FreeBSD 6.1 system. Usually we have 6 clients connected to dovecot through IMAPs. These clients are Thunderbird 1.5 programs. After some hours, one or two processed go up to 100% WCPU. As an example, this is what I see when I run 'top':
Apparently this is because the kqueue notify handler gets called constantly. I'm not sure why though.
You can most likely fix this by configuring --with-notify=none
Hi,
I have seen a similar issue on Solaris 9 with 1.0rc7. I don't remember what process it was, but I remember seeing a lot of poll() called.
Restarting dovecot fixed it. The only trace left is a bump in our Cacti graph monitoring the CPU.
Does "--with-notify=none" makes any sense on Solaris 9 ?
Charles
On ven, 2006-08-25 at 02:00 +0300, Timo Sirainen wrote:
On Thu, 2006-08-24 at 21:33 +0200, Nagy László wrote:
Hello,
I'm using dovecot-1.0.b9 on a FreeBSD 6.1 system. Usually we have 6 clients connected to dovecot through IMAPs. These clients are Thunderbird 1.5 programs. After some hours, one or two processed go up to 100% WCPU. As an example, this is what I see when I run 'top':
Apparently this is because the kqueue notify handler gets called constantly. I'm not sure why though.
You can most likely fix this by configuring --with-notify=none
-- Charles Bueche <charles@bueche.ch> sand, snow, wave, wind and net -surfer
Nagy László wrote:
Hello,
I'm using dovecot-1.0.b9 on a FreeBSD 6.1 system. Usually we have 6 clients connected to dovecot through IMAPs. These clients are Thunderbird 1.5 programs. After some hours, one or two processed go up to 100% WCPU. As an example, this is what I see when I run 'top':
last pid: 5111; load averages: 1.34, 1.82, 1.75 up 13+00:04:09
15:26:59 150 processes: 2 running, 147 sleeping, 1 zombie CPU states: 21.2% user, 0.0% nice, 47.7% system, 0.0% interrupt, 31.1% idle Mem: 149M Active, 368M Inact, 196M Wired, 29M Cache, 111M Buf, 255M Free Swap: 5120M Total, 548M Used, 4572M Free, 10% InusePID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 52627 thomas 1 109 0 2940K 1500K CPU1 0 21:49 99.02% imap
When there are two rebellious clients, they occupy 50-50% CPU time. If I restart thunderbird, then all goes well for a couple of minutes. I need to solve this problem. I already had a system crash that was probably caused by the cpu heat. Pleas help me.
You can limit the user's CPU on the server via login.conf as a work around? Also disable kqueue support as Timo instructed.
Cheers, Dominic
Laszlo
participants (5)
-
Charles Bueche
-
Dominic Marks
-
Nagy László
-
Rui Lopes
-
Timo Sirainen