502 Bad Gateway (php-fastcgi processes crashing)

[shadowlink64]

Our site is currently on a linux VPS with DreamHost and using nginx
0.8.53 as the web server and php-fcgi version 5.2.15. On occasion, our
php-fastcgi processes just suddenly crash, and our users are left with a
"502 Bad Gateway" error from nginx. The server is configured to use unix
sockets and not a TCP port.

Our php-fastcgi settings are the following:
PHP_FCGI_CHILDREN = 8 (should be plenty for our traffic)
PHP_FCGI_MAX_REQUESTS = 400 (used to be 1000, we tried lowering to see
if it would help, and nada.)

The http error logs show these sort of error messages:

>> *9 connect() to unix:/home/***/.php.sock failed (111: Connection
refused) while connecting to upstream, client: *****, server: ****,
request: "GET ****, upstream: "fastcgi://unix:/home/***/.php.sock:"
>> *28898 connect() to unix:/home/****/.php.sock failed (11: Resource
temporarily unavailable) while connecting to upstream, client: **,
server: **, request: "GET **", upstream:
"fastcgi://unix:/home/***/.php.sock:"

We wrote a daemon that restarts the nginx web server when it detects the
processes crash, or these error codes pop up, but sometimes restarting
the web server fails to bring back the php5.cgi processes, and our users
are left without any access to our site material for a while. This
approach is also pretty sloppy and doesn't work sometimes.

Why would php lock up and crash like this, and why isn't nginx
automatically reload the php5.cgi processes? Is there another way to
serve php to our users that doesn't use php-fastcgi? (I heard people
mention php-fpm, but I'm not too familar with using it or its
advantages). We think that it might be the php5.cgi processes timing out
waiting for MySQL queries to finish processing, since we can sometimes
crash php5.cgi simply by running long queries on the web site. Any
suggestions on settings we can tweak?

Thanks to anyone who can help.

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,173776,173776#msg-173776