[horde] apache cpu usage?

Arjen de Korte arjen+horde at de-korte.org
Thu Feb 18 17:23:06 UTC 2016


Citeren Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Arjen de Korte <arjen+horde at de-korte.org>:
>
>> Citeren avp at rokeyetee.com:
>>
>>> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>>>
>>>> Quoting avp at rokeyetee.com:
>>>>
>>>>> I'm running Horde on a AWS t2.medium instance - HORDE GROUPWARE WEBMAIL
>>>>> EDITION 5.2.6
>>>>>
>>>>> I've got some funny apache behaviour that just doesn't seem right to
>>>>> me...
>>>>>
>>>>> When I run "apache2ctl status", 99% of the time all threads are in the
>>>>> "W"
>>>>> (Sending Reply) state:
>>>>>
>>>>>    Current Time: Thursday, 18-Feb-2016 10:02:53 NST
>>>>>    Restart Time: Thursday, 18-Feb-2016 09:49:25 NST
>>>>>    Parent Server Config. Generation: 1
>>>>>    Parent Server MPM Generation: 0
>>>>>    Server uptime: 13 minutes 27 seconds
>>>>>    Server load: 0.77 0.77 0.85
>>>>>    Total accesses: 1382 - Total Traffic: 7.7 MB
>>>>>    CPU Usage: u230.64 s11.47 cu0 cs0 - 30% CPU load
>>>>>    1.71 requests/sec - 9.8 kB/second - 5.7 kB/request
>>>>>    20 requests currently being processed, 8 idle workers
>>>>>  
>>>>> _WWWWWW_WWWWW__W_WWWWWW__W.K_...........
>>>>>
>>>>> It seems strange to me that "sending reply" would be the bottleneck?
>>>>>
>>>>> Also when I run top, I constantly see apache procs jumping to the top
>>>>> with
>>>>> up to 50% cpu usage.
>>>>>
>>>>> Most all the connections are ActiveSync.
>>>>
>>>> When an ActiveSync client is configured for "Push", the connection to
>>>> the webserver remains open while it runs the PING command. These
>>>> requests last up to the "hearbeat interval" that is negotiated between
>>>> the server and client unless there is a change detected, when the PING
>>>> requests ends and a new SYNC request is issued. It makes complete sense
>>>> that you would see ActiveSync connections remaining open.
>>>
>>> Thanks for the quick reply.
>>>
>>> I'm not questioning that the ActiveSync connections remain open -  
>>> I get that.  I'm questioning that the connections are in the  
>>> "Sending Reply" state?  And that my CPU usage seems too high to  
>>> me?  I'm wondering if there is some php being called to generate  
>>> the reply that is being sent but it is taking abnormally  
>>> long/excessive cpu?  Just sort of guessing here...  How might I  
>>> track down what is using the cpu or why the connections are in the  
>>> sending state?
>>>
>>> Here are my activesync settings:
>>>
>>> $conf['activesync']['ping']['heartbeatmin'] = 60;
>>> $conf['activesync']['ping']['heartbeatmax'] = 2700;
>>> $conf['activesync']['ping']['heartbeatdefault'] = 480;
>>> $conf['activesync']['ping']['deviceping'] = true;
>>> $conf['activesync']['ping']['waitinterval'] = 10;
>>>
>>> I just changed waitinterval from 5 to 10.
>>
>> That is still an awfully short interval. It will mean that the PHP  
>> process that is kept active for each device that is connected  
>> through ActiveSync will poll the users mailbox every 10 seconds.  
>> Depending on the number of users you have, this may constitute a  
>> fairly significant load. Note that if you have a decent IMAP server  
>> such a short interval is a waste of effort anyway, as the IMAP  
>> server will notify that things have changed.
>
> Why is it a waste of effort? It means that the sync client will be  
> notified of the email sooner.

If immediate notification for new messages is important, it is better  
to use IMAP and be notified by the IMAP server of changes. This will  
be without delay on a modern IMAP server. If that's not so important,  
messages may be delayed by up to heartbeatmin seconds anyway, so the  
notification is not guaranteed to occur within 10 seconds anyway.

None of my users have ever complained about delays in mail delivery,  
even not when I cranked up the interval to as high as 300 seconds.  
YMMV, but from my experience most users don't expect to be notified  
within seconds if new messages arrive.

> Also, there is no way for the IMAP server to notify the activesync  
> library about any changes OTHER than checking it for changes.  If  
> you have a good server with MODSEQ/CONDSTORE/QRESYNC support, this  
> is simply a check of the HIGHESTMODSEQ value and/or NEXTUID  
> (depending on what we are checking). Performance is further improved  
> by using the IMAP cache - which may already know about changes.

Yes. All of these are vital if you have users with huge mailboxes,  
otherwise scanning for new messages may take a lot of resources.

> Not saying that the waitinterval shouldn't be raised, just be aware  
> that a value like 60 seconds means it could take up to a full minute  
> (possibly longer depending on where in the PING cycle the change  
> occurs) before the change is detected and sent to the client.

See above.

>>> Any suggestions on what these should be?
>>
>> If you have a significant number of users connected through  
>> ActiveSync, increase waitinterval to something like 60 seconds (or  
>> more).
>>
>>> Any other tips/advice to lower CPU usage?
>>
>> Which IMAP server are you using and how many ActiveSync devices do  
>> you have connected?
>>
>>> Thanks again.
>>>
>>>>
>>>>> What are recommended settings for apache when running Horde?
>>>>>
>>>>> Any other tips/advice to lower CPU usage?  
>>>>> Thanks.
>>>>>
>>>>>  
>>>>> --
>>>>> Horde mailing list
>>>>> Frequently Asked Questions: http://horde.org/faq/
>>>>> To unsubscribe, mail: horde-unsubscribe at lists.horde.org
>>>>
>>>> --
>>>> mike
>>>> The Horde Project
>>>> http://www.horde.org
>>>> https://www.facebook.com/hordeprojecthttps://www.twitter.com/hordeproject
>>>
>>> -- 
>>> Horde mailing list
>>> Frequently Asked Questions: http://horde.org/faq/
>>> To unsubscribe, mail: horde-unsubscribe at lists.horde.org
>>
>>
>>
>> -- 
>> Horde mailing list
>> Frequently Asked Questions: http://horde.org/faq/
>> To unsubscribe, mail: horde-unsubscribe at lists.horde.org
>
>
>
> -- 
> mike
> The Horde Project
> http://www.horde.org
> https://www.facebook.com/hordeproject
> https://www.twitter.com/hordeproject





More information about the horde mailing list