[Dovecot] High level of pop3 popping causing server to become unresponsive

[Robert Schetterer]

Am 23.05.2012 16:01, schrieb Root Kev:
> Missed CCing on last reply.  See below..
> 
> Also, would having Nagios checking the number of messages in a mailbox
> cause issues with the popping of messages? And/Or would having a user
> accessing the mailbox from two different applications cause issues?  Ie.
> from Outlook and mobile device?  I am under the impression that a lock file
> is generated which should deal with the issue of contention, deleting mail,
> etc.
> 
> Thanks for any information.
> 
> Kevin

i have a different setup as yours ( virtual , sql etc )
with dove 2.0.20 and extrem high pop3 traffic
no problem so far

same with low pop3 traffic setup dove 2.1.6
no problem reported

anyway use imap

where are your confs and logs ?

> 
> 
> Sorry for the delay in responding, long weekend in Canada...
>>
>> When trying to SSH into the server, the server prompts for user name then
>> password, then just hangs.  Same if there is already a console connection
>> over, when trying to SU to root, it just hangs after entering the password.
>>
>> Our passwords are in the shadow file, and because this is a server
>> dedicated for this task, there is only the default linux users, and maybe 8
>> other user accounts in the shadow file.
>>
>> There shouldn't be high IO as all this box does is postfix, pop3ad and
>> dovecot.  This box is seeing less then 3000 emails a day, and only has 5
>> mailboxes on it.
>>
>> Thanks for the continued suggestions...
>>
>> Kevin
>>
>>
>> On Sat, May 19, 2012 at 3:33 PM, Timo Sirainen <tss at iki.fi> wrote:
>>
>>> On Fri, 2012-05-18 at 09:21 -0400, Root Kev wrote:
>>>> During the last time that the load went up, it became unable to login /
>>> su
>>>> to root for the entire period that dovecot was running, we had to kill
>>>> dovecot and go back to Popa3d until the mailq was cleared up.  We are
>>>> running CentOS 5.6 server.  Based on TOP running at the time the CPU
>>> usage
>>>> was running under 10%.  Once Dovecot was killed, we were then able to
>>> log
>>>> in /su again.
>>>
>>> Like Kelsey said, a very high disk IO might explain this, although
>>> normally the login should still eventually succeed. Another thing I'm
>>> wondering is if some process limit reached. How does the login/su fail,
>>> does it just hang or immediately fail with some error?
>>>
>>>> We were under the impression that checking to shadow directly should be
>>> the
>>>> fastest and least amount of overhead, is any of the other ways to
>>> connect
>>>> have less load on authentication to PAM?
>>>
>>> Your passwords really are in /etc/shadow file, not LDAP/something else?
>>> I don't think the problem is with authentication. Reading /etc/shadow is
>>> pretty fast (unless maybe if it's a huge file) and it anyway can't block
>>> login/su from working.
>>>
>>>
>>>
>>
> 


-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria