Search results

I think your MySQL is the bottle neck which causes high I/O wait, and stall all PHP processes, which causes LSWS to start more PHP processes. Maybe merging posts will cause MySQL to block and takes long time to process? Please post your lsphp configuration for reviewing.

chmod 0755 /usr/bin/gcc, after finish compiling PHP, do chmod 0700 /usr/bin/gcc.

That's normal, used to allow "0" which means disabled, the real threashold was set to 1073741823. You can ignore the warning.

I/O wait is most likely cuased by heavy random access to HD, I don't know if there is really any corelation with quick edit. If yes, you need to check the HTTP request used for quick edit and find out why.

You need to restart twice to release the ANY listener in order for starting the IP listener. not a problem for the web console.

Yes, that's correct.

Not possible now, will add a version number in the phpinfo page. Anyway, the web console will always use the latest version.

If you use suEXEC, you can strace the php process when experiencing the problem.

"Extra PATH environment" in the compile PHP page.

auto update initiated.

trouble shooting tips: http://www.litespeedtech.com/support/wiki/doku.php?id=litespeed_wiki:php:lsapi strace the PHP process or even gdb it, suhosin may cause trouble I believe.

You cannot use both, have to pick one.

forgot to apply the fix to 4.0b1 branch, just updated 4.0b1 package to address this.

Maybe they are in a infinity loop. You can try gdb attach to those processes. gdb attach <pid_of_ruby> bt Also check http://www.litespeedtech.com/support/wiki/doku.php?id=litespeed_wiki:ruby_debug

Yes, it should.

You need to strace the ruby processes that stop working.

Automatically, but configurable via environment variables. http://www.litespeedtech.com/ruby-lsapi-module.html

Yeah, I think your site can be cached.