<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
miradev wrote:
<blockquote
cite="mid:0a4562fb2bc9f3f3acefbbad828d44f4.NginxMailingListEnglish@forum.nginx.org"
type="cite">
<pre wrap="">We've been running nginx + spawn-fcgi for 6 months without any issues. Until one morning I come in and all our sites are down because there were no php-cgi processes running. Obviously I'm keen to not have this happen again. I could make use of something like monit to monitor the php-cgi processes, but even a few minutes down time (waiting for a monit cycle) is not good.
The only article on this I've been able to find so far is this one: <a class="moz-txt-link-freetext" href="http://blog.taragana.com/index.php/archive/how-to-stop-crashing-hanging-of-php-cgi-spawn-fcgi-with-nginx-lighttpd/">http://blog.taragana.com/index.php/archive/how-to-stop-crashing-hanging-of-php-cgi-spawn-fcgi-with-nginx-lighttpd/</a>
</pre>
</blockquote>
I had a very similar problem when using lighttpd+spawn-fcgi. We had
moved from Apache about 3 years ago because of load issues with mod_php
to lighttpd+spawnfcgi+php. This worked fine for a while, but as our
load increased we started to see PHP being unresponsive, and lighty
returning 503s.<br>
<br>
After some digging I found the cause was the way spawnfcgi handled
incomming requests in conjunction with PHP's internal
PHP_FCGI_MAX_REQUESTS setting. This setting is set to 250 by default in
PHP, and when this limit is hit PHP recycles the child thread. During
this recycle spawnfcgi would continue to handle requests, pass them to
the recycling thread, get no response, and in turn lighty would return
a 503. IIRC this would also cause the recycling thread to die, slowly
killing off all the threads and PHP completely.<br>
<br>
Playing with PHP_FCGI_MAX_REQUESTS helped in the short-term but we
continued to experience the problem, so when I heard of nginx I quickly
switched to nginx+php-fcgi (using the -b switch). Since then I've yet
to see an issue, and we've had ~100 production sites running on that
stack for over 2 years. Since starting to use supervisord we've begun
the process of moving the rest of our ~500 domains/sites over to to
that stack.<br>
<br>
Using PHP `-b` in my experience is rock-solid. Running it under
supervisord means that if it dies it is brought back up straight away.
This does not affect nginx, and you can always show a nice error page
should this case happen - I remember that if php went down hard under
mod_php it would cause apache to fail also. Bad times.<br>
<br>
My suggestion is to get rid of spawnfcgi and install supervisord.
Here's the supervisord config I use on my dev machine:<br>
<br>
[fcgi-program:php]<br>
user=nginx<br>
command=/usr/bin/php-cgi -c /etc/php5/php.ini -b /tmp/php.socket<br>
socket=unix:///tmp/php.socket<br>
autostart=true<br>
startsecs=5<br>
startretries=3<br>
stopwaitsecs=10<br>
environment=PHP_FCGI_MAX_REQUESTS=50,PHP_FCGI_CHILDREN=4<br>
<br>
Some on the board suggest having nginx running under supervisord also,
but I'm a little worried about that approach; if supervisord goes down
for any reason on a live server everything goes down, whereas if nginx
is kept separate and supervisord goes down nginx can continue to serve
requests (albeit error pages) while supervisord comes back up and
brings your app back online (php, database, memcached, etc).<br>
<br>
Our production runs:<br>
supervisord > php-fcgi, mysqld, memcached, and a number of python
"services" (our webapp layer)<br>
monit > nginx, supervisord, sshd, other "system" level important
daemons<br>
which means if supervisord goes down for any reason, it'll only be down
for 1min until monit can bring it back up. Since memcached is killed
our webapp is brought back up in a "clean" state. Users are asked to
log in again, but this rarely (or, rather, is yet to) happens and is a
mild inconvenience for them.<br>
<br>
Give it a try. All these technologies are highly configurable and there
are many permutations. To find your optimal configuration is going to
take experimentation. It's not like Apache where there's only one
"right" way to do things; you've got more control - make use of it!<br>
<br>
<div class="moz-signature">-- <br>
<div
style="font-family: sans-serif; font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: 1.1; font-size-adjust: none; font-stretch: normal; width: 300px; color: rgb(51, 51, 51);">
<p><strong>Phillip B Oldham</strong><br>
ActivityHQ<br>
<a href="mailto:phill@theactivitypeople.co.uk">phill@activityhq.com</a></p>
<hr size="1">
<p style="font-size: 90%;"><strong>Policies</strong></p>
<p style="font-size: 90%;">This e-mail and its attachments are intended
for the above named recipient(s) only and may be confidential. If they
have come to you in error, please reply to this e-mail and highlight
the error. No action should be taken regarding content, nor must you
copy or show them to anyone.</p>
<p style="font-size: 90%;">This e-mail has been created in the
knowledge that Internet e-mail is not a 100% secure communications
medium, and we have taken steps to ensure that this e-mail and
attachments are free from any virus. We must advise that in keeping
with good computing practice the recipient should ensure they are
completely virus free, and that you understand and observe the lack of
security when e-mailing us.</p>
<hr size="1">
</div>
</div>
</body>
</html>