[RCD] Revisiting ancient issue - Apache2 100% CPU when competing for UW-IMAP
till at php.net
Tue Sep 28 14:13:19 CEST 2010
On Tue, Sep 28, 2010 at 2:10 PM, Rimas Kudelis <rq at akl.lt> wrote:
> 2010.09.28 14:57, till rašė:
>> On Tue, Sep 28, 2010 at 1:45 PM, Rimas Kudelis<rq at akl.lt> wrote:
>>> 2010.09.17 11:29, A.L.E.C rašė:
>>>> On 17.09.2010 10:22, Rimas Kudelis wrote:
>>>>> For a record: I am using courier-imap, and I too have this problem from
>>>>> time to time (e.g. now). So it's definately not UW's fault. I think when
>>>>> I googled for it, it appeared to be a bug in PHP, isn't it?
>>>> Probably it's PHP's fault and maybe relied on specific PHP+Apache
>>> I'm having this problem again, for about three hours now. Is there
>>> anything I could look for in my logs or any other means of debugging
>>> that would help?
>> Yes there is! :D
>> So to figure out what happens when RoundCube is used, I suggest you
>> install xdebug and temporarily enable profiling of all requests.
>> Beware though - the cachegrind files are huge and tend to eat
>> diskspace quicker than you think. So make sure to watch the directory
>> they are saved to.
>> In a nutshell!
>> sudo pecl install xdebug
>> [depending on your PHP install, you may or may not have to manually
>> insert the following into php.ini: extension=xdebug.so]
>> Then, use the following directives in php.ini:
>> Depending on your setup, you will need to restart PHP/Apache.
>> To analyze the files:
>> This will allow you to troubleshoot where most time is spend and I
>> guess this will either allow us to fix a bug (or more), or allow you
>> to troubleshoot your setup and improve it.
>> If no one finds any errors in my writeup, I'd also add this to the wiki.
> Thanks Till!
> The thing is: if I restart Apache, I lose the dead process, and the time
> it appears next time will be rather unpredictable. Is there perhaps
> anything possible that doesn't involve apache restarts?
> By looking at the logs, I now know the email user who logged on in that
> session, and the 5 minutes time interval when the CPU usage rose up.
> What I don't know is what exactly that process is still doing and why
> it's connection is stuck in a CLOSE_WAIT state...
I suggest you install Xdebug now and periodically check what the
profiler left for you.
Otherwise, there is no way to inspect what happened. At least none
that I know of.
You could also use valgrind on Apache, but that also requires some
sort of setup:
List info: http://lists.roundcube.net/dev/
More information about the Dev