FastCGI problems


Hi, lately I’ve been running into a lot of problems with FastCGI. I’m getting a lot of errors in my log files similar to the following:

[Fri Jan 21 07:57:15 2011] [error] [client 72.92.131.x] FastCGI: incomplete headers (0 bytes) received from server “/home/xxx/”, referer:

[Fri Jan 21 07:57:15 2011] [error] [client 66.249.68.x] FastCGI: comm with (dynamic) server “/home/xxx/” aborted: (first read) idle timeout (60 sec)

After, say, 100 or so of these errors, my site eventually becomes unavailable. After that, no PHP scripts are able to run.

My config is:

AddHandler fastcgi-script fcg fcgi fpl
AddHandler php-fastcgi .php
Action php-fastcgi /cgi-bin/dispatch.fcgi

export PHPRC=/
exec /dh/cgi-system/php5.cgi $*

PHP Version 5.2.15
Server API CGI/FastCGI
Loaded Configuration File /home/xxx/

I’m just wondering if anybody can spot anything obvious that looks wrong. My site uses a (correctly loaded) custom php.ini, PHP5 and is configured for FastCGI (so says phpinfo).



Try switching over to “regular” CGI mode.

I’ve been asked recently to change the auto-installers to support the new PHP5.3 - which I’ll try to get around to doing in the next day or so (real busy looking for work atm). Hopefully ionCube support will be an easy task with the new system DH have and will solve memory issues of heavier sites.


hi sXi, thanks for the tip. My site is on a Private Server with over a gigabyte of memory allocated (800 MB free). I do have a few cron jobs that run PHP scripts. It’s possible that they could be using a lot of memory, but I wouldn’t have thought over 90 MB.

Are you saying in a roundabout way that changing to cgi would dramatically reduce the memory usage of PHP? (I’m guessing at the expense of performance). Thanks, I’ll give it a whirl …


As a start, though, setting PHP_FCGI_CHILDREN has no benefit in the environment we have set up — the FastCGI module will launch extra PHP interpreters as necessary. Remove that line and see if things improve.


Just posting back as I’ve now tried removing the PHP_FCGI_CHILDREN setting from the fcgi wrapper, but it didn’t solve the problem.

I noticed PS server memory usage went down quite a lot after I changed the setting (which is a good thing), but it didn’t cure the underlying issue as the same darned FastCGI error crashed the server again about half an hour afterwards.

I postponed making the switch to ‘normal’ cgi (sXi’s suggestion) as I thought I might be able to get away with andrewf’s suggestion which seemed a bit less severe, but I think I might try sXi’s tip now to see if it improves things.

I appreciate the help so far, thank you guys.



Well, it looks like switching to plain old cgi has stopped the problem, which is great as I now have a stable website. However, I’m no longer getting the performance benefit of FastCGI and I still don’t know the underlying reason for the original problems.

I saw mention somewhere of a 90 MB limit in php.ini. I’m not sure if exceeding this limit is the reason for the error messages that I initially reported. But, if so, is this 90 MB a limit placed on us by DreamHost, or can we increase it?

Apologies, if I am talking nonsense, but I’d like to find out the root cause, so I can switch back to FastCGI at some point.



correct me if i’m wrong, but if you are on a private server, then your php memory limit = private server memory size (roughly)


Yes, I agree, but I’m not sure if it is the memory setting or not causing the problem because once I made the switch to CGI (without changing php.ini memory setting), I have even less server memory available, but no error messages. Therefore, it seems to me like there must be some other reason why FastCGI was crashing.

Sometimes, I had 800 MB free memory on the PS when the errors were occurring. My server is now using a lot more memory (because I’m losing the some of the benefits of FastCGI), but there hasn’t been a problem on my server for 24 hours (and previously, I would have had at least ten crashes during that time).

I’d still like to switch back to FastCGI because memory usage on my server is now at least double what it was before (and it’s therefore costing me more money), but I still don’t understand properly why the original problems might have occurrred and I don’t want to switch back to FastCGI until I do.


@ John Did you ever work out why fastcgi is demanding so much memory? I have the same issue on my VPS. I first thought it was XCache and or Google Pagespeed, but it seems FastCGI eats a lot of memory as well.