By foxtrotcharlie on

One of my sites on shared hosting (PHP 5) which uses FastCGI is giving me lots of timeout errors, which go something like this:

A timeout occured while waiting for the script output (in: /usr/www/users/sitefolder/index.php).

This normally only happens for a logged in admin user, particularly on the modules page, but also on other admin pages. Anonymous users can browse the site fine without seeing these errors.

When I queried the hosting company (Hetzner) about this, they said the following:

the domain is exceeding its maximum number of allowed PHP processes. I would suggest that you would need to take a look at the code of the site and find out why the PHP connections are not being closed properly.

in the apache logs, this is seen often:

[Thu Oct 22 10:34:44 2009] [warn] [client 127.0.0.1] FastCGI: scheduled the restart of the last (dynamic) server "/home/httpd/cgi-bin/php5-fcgi-starter.fcgi" process: reached dynamicMaxClassProcs (10) (in: /usr/www/users/sitefolder)

When I look at the drupal logs, I am seeing a lot of 'Duplicate entry...INSERT INTO menu_router...' errors, but I'm not sure if this is related.

Anyone got any advice on how I try and debug this?

How many php processes should drupal be creating/running?

How are new processes started?

Thanks :-)

⋅ Categories: Drupal 6.x

Comments

gpk’s picture

gpk commented

what is the value of PHP setting max_execution_time? How does this compare with the time you spend for pages like the modules page to build/display? TBH it might not be PHP timing out as such, since you usualy get the error "max_execution_time exceeded" in this case. Could be Apache timing out waiting for PHP to do its stuff. I wonder if an Apache timeout setting is too low..?

Drupal core doesn't create any additional PHP processes. I wonder however if a contrib module is changing this behaviour. You might want to try disabling contrib modules on a test instance of your site.

gpk
----
www.alexoria.co.uk

foxtrotcharlie’s picture

foxtrotcharlie commented

Thanks gpk.

The value for max_execution_time is 55, but I also suspect this is not it. I'll start disabling modules to see if a contrib module is the culprit.

Charles

Drupal development, Cape Town, South Africa

dieterm’s picture

dieterm commented

Hi,

I'm having the same problem with HETZNER. They keep on telling me that the problem is wiht my code. I strongly disagree because these scripts were running smoothly since 2007. I recently moved my hositng from Hetzner Germany to SA and then all these errors started.

Did you manage to sort the problem out with Hetzner ?

regards

foxtrotcharlie’s picture

foxtrotcharlie commented

Hey Dieter. No, I'm still experiencing the same problem. I'm also experiencing it on another drupal 6 site that's hosted with hetzner. Hetzner allows you to set the memory_limit to 50MB, but that hasn't helped with either site. On this other site, it's happening when I try to clear the cache. If I manage to sort it out, I'll post back here.

Charles

Drupal development, Cape Town, South Africa

gpk’s picture

gpk commented

Might be worth having a play with devel.module to see if you can spot a pattern in terms of page build time/memory used. Sounds as if your host may have some restrictive limits and you are hitting one somewhere. Best to try devel on a dev site first in case it causes other problems! Also if your site/server is busy I wonder if it could be a "server overloaded" problem. The actual error message seems to be saying something else but given that it seems to happen only on pages with a heavy overhead maybe the error message is a bit off or is a symptom of something else. Suggest you encourage your host to dig a bit deeper etc. Thousands (millions?) of Drupal sites round the world don't have this problem! The fact it is intermittent also suggests it is related to server config.

gpk
----
www.alexoria.co.uk

funana’s picture

funana commented

Same here, Hetzner also.

GreyHawk’s picture

GreyHawk commented

I'm having the same issues, but with a site hosted with iPower.

foxtrotcharlie’s picture

foxtrotcharlie commented

I haven't been able to get to the bottom of this, so have decided to move my sites away from Hetzner onto my own VPS...

Charles

Drupal development, Cape Town, South Africa

NaX’s picture

NaX commented

I am also with Hetzner and have the same problem.
After some frustration and a client begging me to workout what the problem is, and support guys telling me there should not be a problem, I decided to enabled SSH and have a looked around. Admin's and support guys don't like this much :)

It looks like the problem started with them moving to fastCGI.

And there are a few very important settings at play here, from what I can see.

PHP: max_execution_time - override-able using set_time_limit()
Apache: Timeout (default 300)
FastCgiConfig: -idle-timeout

The problem I see is that the FastCgiConfig -idle-timeout is set to 60.
If your application is not outputting anything then after 60 sec you will hit the fastCGI idle-timout regardless of using set_time_limit() or the Apache Timeout.

I found a good explanation here:
http://serverfault.com/questions/80929/disable-the-timeouts-on-apache-ht... and http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html

The problem I am having is that even if you do output and use the flush function nothing changes.

The only thing I have not been able workout is if a process watcher is not also at play here or if there is maybe a 4th setting also affecting things.

FYI: The error I get is:
A timeout occured while waiting for the script output(/path/to/file.php)

Also note that I have reproduced this error outside of drupal. Easy, just have a script that loops for longer than 60 sec.

bluegray’s picture

bluegray commented

Got the same problem - haven't called Hetzner yet, but glad to see it's not only me...