IMAP processes out of control

Andrew Morgan morgan at orst.edu
Wed Sep 23 16:52:48 EDT 2015 

You should be able to have a LOT of imapd processes with that much RAM. 
On a server with 8GB of RAM, I have maxchild=4000 for imap and 
maxchild=1000 for imaps.

However, it is good to leave lots of RAM for caching, so those limits are 
mainly in place to prevent a bad client from causing a low-memory 
condition on the server.

When you see the process count increasing, you need to identify what the 
"extra" processes are doing.  You will probably be able to identify a 
pattern by looking at the cyrus proc files.  Try this:

   cat ${configdir}/proc/* | sort

The format of the proc file is:

   hostname [IP-address] authenticated-username SELECTed-mailbox

I bet you'll see a lot of connections from one host or user.

You can also use lsof and netstat if things are hanging before the proc 
file is created.

 	Andy

On Wed, 23 Sep 2015, Shaheen Bakhtiar wrote:

> 2 x AMD quad Core 64bit 
> 4G RAM
>
> This morning I woke up to a plethora of complaints that people were not able to access their emails. I remove the aforementioned maxchild from the configurations and restart to server. Once I did that people were able to re-connect with no problems.
>
> I did not have these types of problems with the older version (I believe was 2.3.19). Just since I upgraded to the latest version of Cyrus. 
>
> Current version is:
> [root at postoffice ~]# dnf info cyrus-imapd
> Last metadata expiration check performed 1:06:02 ago on Wed Sep 23 07:12:41 2015.
> Installed Packages
> Name        : cyrus-imapd
> Arch        : x86_64
> Epoch       : 0
> Version     : 2.4.17
> Release     : 9.fc22
>
> Running on Fedora Core 22 64bit
>
>> On Sep 23, 2015, at 7:44 AM, signaldeveloper at gmail.com wrote:
>> 
>> Again this is active sync devices that are connecting with a ton of pushed folders. The more you tell it to sync (folders) the more processes it's going to fork for each user folder. Is this affecting performance that bad? What's your hardware? 
>> 
>> - Paul
>> 
>>> On Sep 22, 2015, at 7:43 PM, Moby <moby at mobsternet.com> wrote:
>>> 
>>> 
>>> 
>>> On 9/22/2015 18:12, Shaheen Bakhtiar wrote:
>>>>> On Sep 22, 2015, at 2:17 PM, Andrew Morgan <morgan at orst.edu> wrote:
>>>>> 
>>>>>> On Tue, 22 Sep 2015, Shaheen Bakhtiar wrote:
>>>>>> 
>>>>>> It happened again….. although it took longer for it to happen, this has been happening only since the upgrade in Jun.
>>>>>> 
>>>>>> The number of imap processes continues to increase until the server is completely OOM. the increase is drastic and all of a sudden.
>>>>> You should probably set maxchild to a value that won't run your server out of memory.  :)
>>>>> 
>>>>> Have you looked at the processes to see what they have in common?  For example, sometimes an IMAP client will run amok and make hundreds or thousands of connections.  Or perhaps the processes are all stuck waiting on a lock, etc.
>>>>> 
>>>>> lsof, strace, netstat, and your Cyrus logs can help a lot.
>>>>>
>>>>>   Andy
>>>> 
>>>> 
>>>> [shawn at postoffice ~]$ ps aux | grep imapd | wc -l
>>>> 255
>>>> [shawn at postoffice ~]# ps aux | grep imapds | wc -l
>>>> 1
>>>> [shawn at postoffice ~]# ps aux | grep pop3d | wc -l
>>>> 9
>>>> [shawn at postoffice ~]# ps aux | grep timseived | wc -l
>>>> 1
>>>> [shawn at postoffice ~]# ps aux | grep lmtpunix | wc -l
>>>> 1
>>>> 
>>>> Based on that output I changed the configuration file (below) adding maxchild. Most likely all my users have their clients open, and from previous monitoring I average about 200 instances of imapd:
>>>> 
>>>> # standard standalone server implementation
>>>> 
>>>> START {
>>>>  # do not delete this entry!
>>>>  recover       cmd="ctl_cyrusdb -r"
>>>>
>>>>  # this is only necessary if using idled for IMAP IDLE
>>>>  idled         cmd="idled"
>>>> }
>>>> 
>>>> # UNIX sockets start with a slash and are put into /var/lib/imap/sockets
>>>> SERVICES {
>>>>  # add or remove based on preferences
>>>>  imap          cmd="imapd" listen="imap" prefork=5 maxchild=300
>>>>  imaps         cmd="imapd -s" listen="imaps" prefork=1 maxchild=100
>>>>  pop3          cmd="pop3d" listen="pop3" prefork=3 maxchild=5
>>>>  pop3s         cmd="pop3d -s" listen="pop3s" prefork=1 maxchild=5
>>>>  sieve         cmd="timsieved" listen="sieve" prefork=0
>>>>
>>>>  # these are only necessary if receiving/exporting usenet via NNTP
>>>> #  nntp         cmd="nntpd" listen="nntp" prefork=3
>>>> #  nntps                cmd="nntpd -s" listen="nntps" prefork=1
>>>>
>>>>  # at least one LMTP is required for delivery
>>>> #  lmtp         cmd="lmtpd" listen="lmtp" prefork=0
>>>>  lmtpunix      cmd="lmtpd" listen="/var/lib/imap/socket/lmtp" prefork=1
>>>>
>>>>  # this is only necessary if using notifications
>>>> #  notify       cmd="notifyd" listen="/var/lib/imap/socket/notify" proto="udp" prefork=1
>>>> }
>>>> 
>>>> EVENTS {
>>>>  # this is required
>>>>  checkpoint    cmd="ctl_cyrusdb -c" period=30
>>>>
>>>>  # this is only necessary if using duplicate delivery suppression,
>>>>  # Sieve or NNTP
>>>>  delprune      cmd="cyr_expire -E 3" at=0400
>>>>
>>>>  # this is only necessary if caching TLS sessions
>>>>  tlsprune      cmd="tls_prune" at=0400
>>>> }
>>>> 
>>>> 
>>>> 
>>>> Comments, concerns??? I’m going to keep observium open on a separate screen and watch when it starts going up, than do the lsof,netstat, and watch logs to see if I can tell why the sudden upticks.
>>>> ----
>>>> Cyrus Home Page: http://www.cyrusimap.org/
>>>> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
>>>> To Unsubscribe:
>>>> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
>>> I have seen that when some of my users fiddle around on their iphone - 
>>> usually the complaints start with "I cannot get mail on my phone" and 
>>> around the same time the process count starts going up.  Very 
>>> intermittent though, and has not occurred since all users upgraded to 
>>> IOS 9.  Just my USD 0.02 worth...
>>> 
>>> -- 
>>> --Moby
>>> 
>>> ----
>>> Cyrus Home Page: http://www.cyrusimap.org/
>>> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
>>> To Unsubscribe:
>>> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
>> ----
>> Cyrus Home Page: http://www.cyrusimap.org/
>> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
>> To Unsubscribe:
>> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
>
> ----
> Cyrus Home Page: http://www.cyrusimap.org/
> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
> To Unsubscribe:
> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

More information about the Info-cyrus mailing list