Agreed with Andy. Possibly an infected machine and a bad outlook hook in that's
trying to send spam over your server. You can also try to setup message
thresholds to combat this IF that is the case.
- Paul
> On Sep 23, 2015, at 4:52 PM, Andrew Morgan <mor...@orst.edu> wrote:
>
> 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@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, signaldevelo...@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 <m...@mobsternet.com> wrote:
>>>> On 9/22/2015 18:12, Shaheen Bakhtiar wrote:
>>>>>>> On Sep 22, 2015, at 2:17 PM, Andrew Morgan <mor...@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@postoffice ~]$ ps aux | grep imapd | wc -l
>>>>> 255
>>>>> [shawn@postoffice ~]# ps aux | grep imapds | wc -l
>>>>> 1
>>>>> [shawn@postoffice ~]# ps aux | grep pop3d | wc -l
>>>>> 9
>>>>> [shawn@postoffice ~]# ps aux | grep timseived | wc -l
>>>>> 1
>>>>> [shawn@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
----
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
