[RCD] Revisiting ancient issue - Apache2 100% CPU when competing for UW-IMAP

till 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
>>>> configuration.
>>>
>>> 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:
>> xdebug.profiler_enable=1
>> xdebug.profiler_output_dir=/dir/with/lots/of/space
>>
>> Depending on your setup, you will need to restart PHP/Apache.
>>
>> To analyze the files:
>> http://kcachegrind.sf.net/
>> http://sourceforge.net/projects/wincachegrind/
>>
>> 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.
>>
>> Till
>
> 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...
>
> Rimas

Hi Rimas,

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:
http://bugs.php.net/bugs-getting-valgrind-log.php

Till
_______________________________________________
List info: http://lists.roundcube.net/dev/
BT/aba52c80


More information about the Dev mailing list