On 2/10/11 5:51 AM, shadowlink64 wrote:
> 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:"

This is a PHP problem and not related to nginx. I've never been happy
using php-fastcgi as a backend without a process manager of some sort.

Your choices include using PHP-FPM, using Supervisord, using another
process manager, or of course, using Apache as a backend to handle PHP
requests only with nginx serving static content and acting as a reverse
proxy the same way you use it now.

If your code will support it, and you want to use PHP-FPM, then
upgrading to PHP 5.3.x may be a good idea as no patching is required to
build from sources.

Additionally, I have seen *anecdotal* reports here and elsewhere that
having your processes listen on a TCP port rather than a Unix socket may
be beneficial.

>
> 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?

nginx didn't start the processes and does not control them.

> 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).

See above. It's a process manager and will restart dead children
automatically.

> 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
>
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://nginx.org/mailman/listinfo/nginx


--
Jim Ohlstein

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx