Comments on: Apache PHP MySQL and Runaway Scripts

By: Leon

Leon — Sun, 19 Apr 2009 14:52:03 +0000

mm. I was seeing similar sleep issues . We run some data processing every minute via cron. We want the script to stop once per minute so the new process can take over.
We did this at the start of the script:
//get start time
$s = microtime(true);

Then once per loop of our analysis script check the time:
$runningfor = round(microtime(true) – $s, 4);
//if its over 60 seconds terminate the script
if($runningfor>60){
die();
}

Hope that helps someone

By: peter

peter — Sun, 03 Aug 2008 17:04:05 +0000

VovaNux,

It depends on how you design your application. If you’re using PHP Fast-CGI to serve requests PCNTL will be available You also ca get it compiled in with Mod_PHP I think though it would be dangerous as you will can get alarm triggered while in Apache code etc.

By: vovaNux

vovaNux — Sun, 03 Aug 2008 06:48:17 +0000

pcntl functions are available from command line only (if you have Linux). That’s why it is quite hard to use them as most of your scripts are not run from the command line

By: PHP

PHP — Tue, 29 Jul 2008 08:57:10 +0000

Very beneficial performance tunning tips has been provided. Thanks.

By: peter

peter — Sun, 25 May 2008 00:37:47 +0000

Lauri,

I’ve did the test with mysql_xxx functions for you. There is no difference – MySQL calls are not counted towards execution time. If it works differently in your case please provide example code and PHP version – I’m really curious.

By: lauri

lauri — Sat, 24 May 2008 19:11:29 +0000

I’m not sure that you can actually have a completely runaway MySQL query. Eventually the max_execution_time will be reached, as the execution of mysql_?, PDO etc are counted towards the max_execution_time, and the script is aborted. In you tests however, the sleep() function that you used to ’simulate’ a query is not counted towards max_execution_time. In fact, in the 2nd example only the for() instructions count as execution time. So even this script will eventually abort, but as the for() instruction take svery little CPU time it seems to just go on forever. AS for runaway queries, the test surely show something, but exactly what?

By: peter

peter — Sat, 24 May 2008 07:14:50 +0000

Thanks Rasmus,

But what is about using this approach for PHP-FastCGI, Which is exactly environment which I found it working ?

When if we stick to apache what do you propose as alternative ? To have some watchdog script checking running scripts and killing apache processes if they were serving request for too long ? Not overly user friendly. Though I guess you can make front server to detect and error and display nicer message.

By: Rasmus

Rasmus — Sat, 24 May 2008 04:48:36 +0000

Using signals in userspace PHP is a really bad idea. You have no idea how the web server code you are running inside might be affected which is why that note is in the documentation. Apache1 will send a SIGALRM when the configured timeout expires, but signal handling in Apache2 is completely different, so when you start debugging signals and timeouts you need to be very explicit about which environment you are in, and for Apache2, which mpm you are running. In order to not clash with Apache’s signal handling, PHP uses an itimer which triggers a SIGPROF (normally used for profiling). A SIGPROF counts cpu time, so yes, if you do nothing but sleep or you are blocked on io from somewhere else, then you need to rely on the Apache SIGALRM to time you out. But for any sort of busy loop, it will kick in.

The nasty thing is that 3rd party libraries can hijack any of these signals and it can be really hard to figure out who is doing that on you if you aren’t getting the timeouts you are expecting. There isn’t much neither Apache nor PHP can do about that.

By: peter

peter — Fri, 23 May 2008 04:37:29 +0000

Absolutely. If PHP queries MySQL Apache child will be busy and client stop will not abort the process.

By: jeffatrackaid

jeffatrackaid — Fri, 23 May 2008 01:07:16 +0000

I think the hanging behavior is what I see on a client’s site. On this site, they have some horrendous selects that dump to TMP tables. There are a few selects that take nearly a minute to run. I think the client abandons the page but the script or at least the select continues to run. I will have to check more closely to see if we can replicate this and confirm the results. On the database that runs the queries, the selects quickly pile up due to table locking. The issue then snowballs as the web servers are quite busy during peak with 100’s req/sec. As the searches hang the apache slots, the site’s performance degrades.