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 Lopes
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20060825/84641196/attachment.bin>
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 at 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% 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.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 >