GoDaddy: undocumented 20-second CPU time maximal execution limit? (python, ELF, etc)
16th October 2007
Today, setting up a relatively serious (in CPU resources needed) web-system, I ran into a weird problem of python scripts ending prematurely. After some investigation, it looked like any process which uses up more than 20 seconds of CPU time, is automatically killed. To verify this, I wrote an infinite loop in C,
-
int main () {
-
unsigned int i;
-
-
for (i = 0; i <2 ; i++ ) {
-
i = 0;
-
}
-
-
return 0;
-
}
compiled it and executed several times on the GoDaddy shared hosting server. I did observe the program running for the maximum of 20 seconds of CPU time, not a second more. Please note, that 20 seconds of CPU time can be much more of "real" time, if the script isn't using 100% of CPU, which often the case for shared hosting. Thus if you have in your php.ini max_execution_time set to, say, 60 seconds, your php script may actually execute as long as one minute; but I'm pretty sure that if your script has lots of CPU-intensive procedures, then as soon as it uses 20 seconds of CPU time, it will be terminated (however, this statement still needs checking - anyone?).
To verify, I also created a cron job with the same file. It ran for 30 seconds CPU time.
Strangely, this behaviour is not documented anywhere.
This limit may also explain a number of other problems, if you have heavy web-applications: they just might be killed before they are finished, causing errors.
I do understand the reason for this limitation, and am sure similar limitations exist in other shared hosting environments. The only important thing here is that this limit should have been documented and even put upfront somewhere in the hosting plans descriptions.
I also wonder if the limit is the same for all godaddy shared hosting plans, or if it differs. 20 seconds when executed from PHP, and 30 seconds when executed as a cron job were observed on the Deluxe Linux Hosting plan.
Extensions, additions and comments are welcome.
October 19th, 2007 at 16:18
[...] GoDaddy: undocumented 20-second CPU time maximal execution limit? (python, ELF, etc) [...]
June 4th, 2008 at 18:51
[...] it’s better to have a 125MHz-clamp on CPU, than have a 20-seconds maximal CPU time limit [...]
October 19th, 2008 at 7:01
I guess you could probably try this out with a PHP script which has code like below:
sleep(10);
echo 'The script has been running for 10 seconds';
sleep(10);
echo 'the script has been running for 20 seconds';
sleep(10);
echo 'the script has been running for 30 seconds';
Etcetera? Not sure, just an idea.
Cheers,
Sid
October 19th, 2008 at 10:46
Sid,
that won't show anything, as "sleeping" doesn't consume CPU time as actively as an infinite loop - so this just is not the CPU time you would be trying to measure with this PHP script.
Moreover, as my little experiment with an infinite loop did work, there is no need in any additional testing.
October 19th, 2008 at 15:55
Ah, I did not realise the difference.
I'm on GoDaddy right now, and my scripts seem to be running fairly well, and Wordpress 2.6 with decent speed, although I noticed that the Deluxe plan had better performance than my Economy hosting plan, although this might have been a placebo.
Anyways,
Cheers,
Sid
February 13th, 2009 at 18:30
Thanks guys for this info,
I have been trying to find the bug for a while now. I had a CPU intensive cron job that never finished, now I know why.
If you have SSH access, you can sometimes see "terminated" being printed after 20 seconds or so when you run the script.
February 13th, 2009 at 21:45
Stephan, you are welcome.
I haven't yet tried the new SSH access GoDaddy has on offer - to enable it, I have to accept a phone call from US
March 8th, 2009 at 0:02
FYI: BE FORE WARNED!!! If you enable godaddy ssh, you had better backup your databases first. They move you to a different hosting server behind a different firewall with a different db host. So you have to restore your db to that new db host, and update your php scripts/config files to use that new db server. You can probably expect to have a minimum of several hours downtime. The reason they call you first is to verify that you actually want to do this and are prepared to do the change over.
March 8th, 2009 at 15:27
Randy,
thanks for sharing.
I guess DB restoration is very easy with their "backup/restore" functions (well, it should be).
May 12th, 2009 at 11:47
Thanks for this. I've worked it into my PHP download wrapper. A must have for resumable streams and downloads when you don't what errors in the download data.
eg.
define ( 'START_TIME', time() );
....
....
$handle = @fopen( $filename, "r" );
if ($handle)
{
dlog( "fseek: {$this->getStart()}");
fseek( $handle, $this->getStart() );
$count=0;
while (!feof($handle))
{
$buffer = fgets($handle, 8192);
echo $buffer;
ob_flush();
if ( (!(++$count % 20)) && ((time()-START_TIME) > 540) )
{
exit;
}
}
}
fclose($handle);
...
June 14th, 2009 at 10:54
It seriously would not surprise me at all. I'm actually quite annoyed that Godaddy crams close to 4000 virtual hosts on an ip. I say an "IP" because they may have one IP distributed out to several physical capacity servers. I really hope it's not just one physical server, no matter how hyrbrid. What happens if one the IP of the server your site is hosted on, gets ddos'd? Probability wise (one in 3500-4000 chance) it will be directed at someone else's site, that is running behind the same IP as you. To get back to the topic at hand, Godaddy HAS to think about CPU delegation or else their processor just won't be capable of handling the sheer amount of diverse sites its running. GoDaddy does have some of it's server variables set to modest limits. I have for instance actually checked certain server variables, in order to increase them for my particular needs. GoDaddy, if you read this, I know you're making goooood money now. Why don't you be more reasonable with your schemes. Scale back on the marketing maybe, and put the money to quality of infrastructure. I know I know... the colo's are more expensive to run if you have more machines's ya ya ya. Somebody's got to do it!