On Tue, Sep 28, 2010 at 2:10 PM, Rimas Kudelis rq@akl.lt wrote:
2010.09.28 14:57, till rašė:
On Tue, Sep 28, 2010 at 1:45 PM, Rimas Kudelisrq@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