[horde] apache cpu usage?

Michael J Rubinsky mrubinsk at horde.org
Thu Feb 18 17:45:59 UTC 2016


Quoting Arjen de Korte <arjen+horde at de-korte.org>:

> 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.

Not to dispute your other valid points, but notifications won't take  
heartbeatmin to be sent. Once a change is detected, the PING request  
immediately exists and notifies the client there is a change, at which  
point the client issues the SYNC request to fetch the change. The  
heartbeatmin setting is used to force the heartbeat interval about a  
certain minimum in case the client requests something shorter. From  
the client's perspective, ith heartbeat, the longer the better - since  
it takes more battery power to initiate new connections vs keeping a  
PING request open.

Also, you have to take into account the fact that with ActiveSync you  
get other groupware data synced as well - with one connection and  
account. If you use plain IMAP for email, you will still need another  
method of syncing the other data (if that's important to you, of  
course) which will require another connection (and thus more  
battery/resource usage).

> 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.

I guess since I do a lot of testing on these devices, I don't want to  
wait 5 minutes to see if an email is synchronized correctly :)

>> 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
>
>
>
> -- 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5751 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/horde/attachments/20160218/f0820c61/attachment-0001.bin>


More information about the horde mailing list