Fast CGI (spawn-fcgi / php-cgi) crashes/dies/hangs

Apologies if this is too off topic. My problem is not directly related
to nginx.

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:
http://blog.taragana.com/index.php/archive/how-to-stop-crashing-hanging-of-php-cgi-spawn-fcgi-with-nginx-lighttpd/

As this is a popular combo with nginx, I was wondering if anyone here
had any advice, or even just some more articles for me to RTFM?

Thanks.

Posted at Nginx Forum:

Use php-fpm instead :slight_smile:

mike Wrote:

Use php-fpm instead :slight_smile:

This would require re-compiling PHP, which I am not prepared to do
unless critical. Too many other potential head-aches from this.

Posted at Nginx Forum:

On Tue, Dec 08, 2009 at 03:33:05AM -0800, Michael S. wrote:

well spawn-fcgi not working properly could be considered critical.

have you tried the latest stable spawn-fcgi, and then the latest beta?

It won’t work anyway.

Repeat after me.

spawn-fcgi is not a process manager. spawn-fcgi is not a process
manager.
spawn-fcgi is not a process manager. spawn-fcgi is not a process
manager.
spawn-fcgi is not a process manager. spawn-fcgi is not a process
manager.
spawn-fcgi is not a process manager. spawn-fcgi is not a process
manager.
spawn-fcgi is not a process manager. spawn-fcgi is not a process
manager.

No version of spawn-fcgi will help you (or the OP) with crashing PHP
processes. Use a process manager, like supervisord, god, runit, upstart,
sysvinit, daemontools or whatever suits you, that can actually restart a
crashed PHP.

(shameless plug: consider supervisord with ngx_supervisord, announced
here recently)

Best regards,
Grzegorz N.

roger that. just wondering why they’re crashing under spawn-fcgi to
begin with.

and also … we all know php-fpm is a process manager too. two birds
with the same stone! :wink:

On Tue, Dec 08, 2009 at 03:52:24AM -0800, Michael S. wrote:

roger that. just wondering why they’re crashing under spawn-fcgi to begin with.

Running php-fcgi with -b option is AFAIK completely equivalent to
running it via spawn-fcgi. spawn-fcgi really has nothing to do with PHP
crashes.

and also … we all know php-fpm is a process manager too. two birds
with the same stone! :wink:

Yup, but the OP doesn’t want to recompile PHP, so sue him :wink:

Best regards,
Grzegorz N.

On Tue, Dec 8, 2009 at 3:55 AM, Grzegorz N. [email protected] wrote:

Once again, you’ve enhanced my statement. You’re right. I’ve been
discussing random php-fpm stuff on IRC and such and was thinking
spawn-fcgi actually -did- something additional that php-cgi -b didn’t
do and had some php guts in it or something.

Time to go to bed :slight_smile:

well spawn-fcgi not working properly could be considered critical.

have you tried the latest stable spawn-fcgi, and then the latest beta?

You could use Apache to serve PHP scripts rather than
spawn-fcgi/php-cgi. Apache’s handling of PHP has been time tested, and
performs as well or better than fcgi in my experience on a high traffic
Wordpress blog.

We use:

proxy_pass http://127.0.0.1:8008;

Apache can listen on several ports.

I had a lot of headaches with fcgi, which made me question why I even
needed it when I had Apache. On a single server Apache handled PHP and
static files for 35 million visitors in a month before we started using
Nginx, so using Apache only for PHP on the backend made sense.

Posted at Nginx Forum:

On Tue, Dec 08, 2009 at 03:59:20AM -0800, Michael S. wrote:
^^^^^^^^^^

Time to go to bed :slight_smile:

Indeed :slight_smile:

Best regards,
Grzegorz N.

Mike,

I know you’re a superfan of php-fpm, and fcgi in particular, but some of
us have very high traffic blogs that require 100% uptime if possible,
which Apache can provide. php-fpm, spawn-fcgi, and php-fcgi are for
small blogs that can afford to experiment, and aren’t going to lose
money when fcgi crashes or hangs.

Apache is rock solid when handling PHP, and this is a fact. fcgi has
stability issues even when the php-fpm patch is installed.

I understand your enthusiasm, but until you’re blog is getting millions
of visitors each month you cannot really test the stability of php-fpm
on your production server.

What’s boggles my mind is hearing so many people recommend any flavor
fcgi for PHP despite all the instability, crashing, and hanging issues
that continue to be unresolved, when nearly every server comes with
Apache which handles PHP in a stable and reliable manner right out of
the box.

Posted at Nginx Forum:

php-fpm handles millions of requests a day for me without an issue.
Apache cannot handle the load on the same hardware.

Go figure.

FCGI for PHP is not only stable but time tested as well. You’ll note
that Zeus, lighttpd, nginx, almost every webserver with a user base
sans litespeed and Apache can only use PHP over fastcgi.

PHP-FPM isn’t for everyone but soon can be. I gave my (as Norsek
pointed out useless) help w/ spawn-fcgi questions. I understand it’s
not an option for some but calling PHP over FCGI unstable is a joke :slight_smile:

This boggles my mind. Apache just for php…

Sent from my iPhone

I managed a forum with a million visitors/DAY. I used nginx with php-fpm
without any problems.

Love nginx + php-fpm :slight_smile:

Best Regards,

Glen L.

Apache is rock solid. That’s a fact. Keep reading to see how many web
sites support this fact.

php-fcgi is unstable, and unreliable. That’s a fact. It’s no joke when a
web site goes down on a production server. Down time is lost money.

The forums are saturated with complaints about the instability and
unreliability of php-fcgi, etc., serving PHP for Nginx and other servers
that don’t serve PHP themselves.

When Apache, or Litespeed, are used on the backend to serve PHP for
Nginx, and those other static file servers like Zeus and lighttpd, there
are zero complaints, because Apache is reliable and stable when serving
PHP.

When you say:

Apache cannot handle the load on the same hardware.

… you must have never used Apache to serve millions of request,
because I have, and I know you have no idea what you’re talking about,
and the system administrators handling some of the biggest web sites on
the Internet also know you don’t have a clue about Apache’s abilities.

You said:

php-fpm handles millions of requests a day for me without an issue.

Post the URL to your web site that handles millions of requests a day,
because I believe you’re claim is a lie. The only site I can find for
you is http://michaelshadle.com/, and that doesn’t get much traffic at
all.

http://community.livejournal.com uses Apache, http://wordpress.org/ uses
Litespeed, http://wordpress.com/ uses Nginx on the frontend with
Litespeed on the backend. http://www.techcrunch.com uses Apache.
http://youtube.com/ uses Apache, they must have switched from lighttpd
because of the memory leak, or maybe because of problems with php-fcgi.

http://wikipedia.org/ uses Apache, and Xcache.

http://news.netcraft.com/archives/web_server_survey.html

Developer October 2009 Percent November 2009 Percent Change
Apache 108,078,535 46.90% 110,201,883 47.17% 0.27
Microsoft 49,723,999 21.58% 49,691,412 21.27% -0.31
qq.com 30,069,136 13.05% 30,069,189 12.87% -0.18
nginx 13,813,997 5.99% 14,988,610 6.42% 0.42
Google 13,819,947 6.00% 13,771,004 5.89% -0.10
lighttpd 1,020,227 0.44% 1,113,605 0.48% 0.03

I guess some of the highest trafficked web sites on the Internet are
using a web server that doesn’t use php-fcgi to handle PHP.

What’s more important is that there is no way to know how many web sites
are using Apache or lighttpd as a backend server to handle PHP, since
those people never complain about problems, and the small number of web
sites that do try to use php-fcgi complain on forums all over the
Internet about problems with reliability and stability.

Those are the facts Mike. Your support for php-fcgi sounds more like an
opinion than a statement based on fact.

I’ve seen your comments here about how much you love php-fpm. Giving
people the impression that php-fcgi is the only option they have to
handle PHP on the backend, can mislead someone into many hours or days
of frustration that can lead them into dumping Nginx, because they blame
Nginx for the problems caused by php-fcgi. I suggest balancing your
advice with other options like Apache.

Posted at Nginx Forum:

nerdgrind wrote:

Apache is rock solid. That’s a fact. Keep reading to see how many web sites support this fact.

php-fcgi is unstable, and unreliable. That’s a fact. It’s no joke when a web site goes down on a production server. Down time is lost money.

The forums are saturated with complaints about the instability and unreliability of php-fcgi, etc., serving PHP for Nginx and other servers that don’t serve PHP themselves.

As they are with Apache dying. Google it.

When Apache, or Litespeed, are used on the backend to serve PHP for Nginx, and those other static file servers like Zeus and lighttpd, there are zero complaints, because Apache is reliable and stable when serving PHP.

Zero complaints? You know this for a fact? Zero? You must be kidding.
Making statements like this does little for your credibility.

php-fpm handles millions of requests a day for me without an issue.

Post the URL to your web site that handles millions of requests a day, because I believe you’re claim is a lie. The only site I can find for you is http://michaelshadle.com/, and that doesn’t get much traffic at all.

That’s out of line. Just because YOU cannot find it does not mean it is
not there. It is, but you don’t know where to look and Mike is not going
to share it to satisfy your need to know. You’re wrong on this one.

Microsoft 49,723,999 21.58% 49,691,412 21.27% -0.31
qq.com 30,069,136 13.05% 30,069,189 12.87% -0.18
nginx 13,813,997 5.99% 14,988,610 6.42% 0.42
Google 13,819,947 6.00% 13,771,004 5.89% -0.10
lighttpd 1,020,227 0.44% 1,113,605 0.48% 0.03

I guess some of the highest trafficked web sites on the Internet are using a web server that doesn’t use php-fcgi to handle PHP.

And some use nginx. As for how they handle PHP, that is speculation.

What’s more important is that there is no way to know how many web sites are using Apache or lighttpd as a backend server to handle PHP, since those people never complain about problems, and the small number of web sites that do try to use php-fcgi complain on forums all over the Internet about problems with reliability and stability.

Exactly.

Those are the facts Mike. Your support for php-fcgi sounds more like an opinion than a statement based on fact.

This may be but your claim that there are zero complaints with Apache
and that Apache is “rock solid” and never goes down is also an opinion
that happens to be wrong. I have myself seen it go down. Of course we
were only handling 4 million requests/day at the time and we were using
Apache with mod_perl to serve a Perl script, so it wasn’t PHP. That’s
why I had supervisord installed. It can restart php-cgi just as easily
(and probably php-fpm but I haven’t tried it) as it can Apache and even
nginx. The fact that I never posted my experience on a forum doesn’t
mean it never happened.

I’ve seen your comments here about how much you love php-fpm. Giving people the impression that php-fcgi is the only option they have to handle PHP on the backend, can mislead someone into many hours or days of frustration that can lead them into dumping Nginx, because they blame Nginx for the problems caused by php-fcgi. I suggest balancing your advice with other options like Apache.

This is a fair comment. Mike loves php-fpm and is perhaps biased. So sue
him.

This “discussion” probably does not belong on the nginx list and should
perhaps be taken private between you two if it needs to continue.

Posted at Nginx Forum: Re: Fast CGI (spawn-fcgi / php-cgi) crashes/dies/hangs


nginx mailing list
[email protected]
nginx Info Page


Jim O.

Jim O. Wrote:

down is also an opinion
nginx. The fact that I never posted my experience
on a forum doesn’t
mean it never happened.

Correction: I used monit to restart Apache at that time. Previously I
had used my own shell script.

Posted at Nginx Forum:

On Tue, Dec 8, 2009 at 4:46 PM, nerdgrind [email protected] wrote:

Apache is rock solid. That’s a fact. Keep reading to see how many web sites support this fact.

It is stable, yes. Does it scale as well? No.

php-fcgi is unstable, and unreliable. That’s a fact. It’s no joke when a web site goes down on a production server. Down time is lost money.

PLEASE give me these thousands of complaints against php-fcgi. The PHP
team should probably hear about them since it is such an epidemic.

The forums are saturated with complaints about the instability and unreliability of php-fcgi, etc., serving PHP for Nginx and other servers that don’t serve PHP themselves.

Perhaps using newer versions of PHP-FPM or something.

When Apache, or Litespeed, are used on the backend to serve PHP for Nginx, and those other static file servers like Zeus and lighttpd, there are zero complaints, because Apache is reliable and stable when serving PHP.

Zeus doesn’t use Apache for PHP. It uses FastCGI. Why? Because it is
decoupled from the webserver and offers better scaling methods.

FastCGI has been around since what, 1994 or something? It might have a
couple flaws according to some folks, but it has proven to be solid,
otherwise commercial vendors such as Zeus would not be using it. Zeus
would not be able to sell their product if PHP support was broken.
Sorry.

… you must have never used Apache to serve millions of request, because I have, and I know you have no idea what you’re talking about, and the system administrators handling some of the biggest web sites on the Internet also know you don’t have a clue about Apache’s abilities.

No, I used Apache, until it took my server load to 40+ and became
unresponsive. Then I switched to Zeus + PHP over FastCGI. Amazingly,
my server load dropped to 2.00 and it was not lagged at all, I had to
load the site to verify it was actually running. It seemed virtually
unaffected.

Post the URL to your web site that handles millions of requests a day, because I believe you’re claim is a lie. The only site I can find for you is http://michaelshadle.com/, and that doesn’t get much traffic at all.

I have a variety of client sites that I host and I don’t need to
justify them to you. I have a 3 node web cluster that hosts multiple
PHP-FPM fastcgi pools with -no- downtime or issues. Total amount of
PHP-based requests is in the millions/day. It would be a breach of my
clients’ privacy to be posting their websites. Call it a lie all you
like, I would not be selling something I didn’t believe in, and you
can take that to the bank.

Apache’s only solution for uid/gid-based execution for PHP would be
suexec. Forget using anything else, it scales even worse. Unless
you’re going to use suexec or multiple Apache instances, you cannot
emulate the pool concept.

http://community.livejournal.com uses Apache, http://wordpress.org/ uses Litespeed, http://wordpress.com/ uses Nginx on the frontend with Litespeed on the backend. http://www.techcrunch.com uses Apache. http://youtube.com/ uses Apache, they must have switched from lighttpd because of the memory leak, or maybe because of problems with php-fcgi.

Maybe you should research first. YouTube has no claims to be using PHP:

Also, WordPress was so impressed by nginx, they were thinking of using
it for their web nodes to simplify their software stack. That would be
a major change though, so who knows if they still are thinking about
it or are happy where they are at.

Livejournal also does not use PHP. It uses Perl, like everything at
Danga seems to.

http://news.netcraft.com/archives/web_server_survey.html

Do you notice nginx’s growing trend? Not to mention 4th on the list?
That is like saying “Porsche sucks, it only has 3% of the car market.
It’s obvious Toyota is better because it has 40%” or something. Apache
is king because it’s been around for a long time, it’s more accessable
and is the default in half the Linux-based server installations out
there.

I’ve yet to have anyone try nginx who didn’t want to go back.

I’ve yet to see anyone complain FastCGI+PHP was too unstable for their
needs.

I guess some of the highest trafficked web sites on the Internet are using a web server that doesn’t use php-fcgi to handle PHP.

Possibly because they aren’t using PHP? Not like you for a “high
traffic blog” site.

What’s more important is that there is no way to know how many web sites are using Apache or lighttpd as a backend server to handle PHP, since those people never complain about problems, and the small number of web sites that do try to use php-fcgi complain on forums all over the Internet about problems with reliability and stability.

Then those people are -idiots- - I said it. I see nginx mailing list
issues daily. Are any of them due to a PHP+FastCGI issue? No. Has that
ever been the breaking point? No. In fact, for most people moving AWAY
from a mod_php model has proven more scalable.

(Hey folks now is time to show those impressive benchmarks you paste
all around IRC and such :p)

Those are the facts Mike. Your support for php-fcgi sounds more like an opinion than a statement based on fact.

You got me there! You’ve got the facts obviously. Even though multiple
ones are wrong. They are ‘facts’ nonetheless.

I’ve seen your comments here about how much you love php-fpm. Giving people the impression that php-fcgi is the only option they have to handle PHP on the backend, can mislead someone into many hours or days of frustration that can lead them into dumping Nginx, because they blame Nginx for the problems caused by php-fcgi. I suggest balancing your advice with other options like Apache.

Or I will give advice as I see fit, as it is advice. If they come to
the list saying their PHP is not scaling properly, then we’ll address
that issue. I mentioned using PHP-FPM but I was willing to try to help
you with spawn-fcgi.

It sounds like you’ve got a crappy platform or crappy code to be
crashing PHP processes. Perhaps the only reason you think Apache is
stable is because it’s acting as a process monitor itself and is
either restarting children and you’re unaware, or is a bit more
resilient to whatever code is crashing your children under FastCGI.

Gentlemen,

I respect your’e opinions, but for all you’re heated desperation to
defend php-fcgi you may have forgotten this thread was started by
someone who found php-fcgi to be unstable, and he hasn’t been able to
find a solution. I found one that worked for me when php-fcgi failed.
Offering a solution to someone that results in the same failure doesn’t
seem to be a solution to me.

Perhaps someone here could give a detailed solution as to how miradev
might solve his problem. Kind of like a how-to explanation. We’re all
here to help each other.

I don’t want to anyone coming here for help only offered one
possibility, when something else might be better suited to their
situation and needs, which is why I posted an alternative.

Apache may not be on the most loved list here, but it can work where
php-fcgi fails. Let’s not ignore this alternative when someone is ready
to switch from Nginx back to Apache, as even the author of WP Super
Cache did just last week. Insisting that php-fcgi is the only way to
serve PHP will slow the adoption of Nginx, because it doesn’t offer
support for PHP itself.

In fact, Wordpress itself has a problem when php-fcgi is used rather
than Apache as the backend to serve PHP

When WordPress detects that FastCGI PHP SAPI is in use, it disregards
the redirect status code passed to wp_redirect. Thus, all 301 redrects
become 302 redirects which may not be good for SEO. The plugin overrides
wp_redirect when it detects that nginx is used.

When WordPress detects that mod_rewrite is not loaded (which is the case
for nginx as it does not load any Apache modules) it falls back to
PATHINFO permalinks in Permalink Settings page. nginx itself has
built-in support for URL rewriting and does not need PATHINFO
permalinks. Thus, when the plugin detects that nginx is used, it makes
WordPress think that mod_rewrite is loaded and it is OK to use pretty
permalinks.

There is also an extensive additional configuration that needs to be
done to avoid problems.

I’ve never heard anyone hear discuss these issues, which means a lot of
people might be losing out on a lot of traffic that could be coming from
search engines because of an SEO problem caused by an incompatibility
between php-fcgi and Wordpress.

Using Apache as a backend eliminates this problem.

Like many of you, I have had my own experiences, and I now have a
multitude of solutions to fit different situations. Although I don’t
know what platform miradev uses to serve his web sites, if it is
Wordpress then using Apache on the backend could save him some headaches
he didn’t even know existed.

Posted at Nginx Forum:

On Tue, Dec 8, 2009 at 6:21 PM, nerdgrind [email protected] wrote:

I respect your’e opinions, but for all you’re heated desperation to defend php-fcgi you may have forgotten this thread was started by someone who found php-fcgi to be unstable, and he hasn’t been able to find a solution. I found one that worked for me when php-fcgi failed. Offering a solution to someone that results in the same failure doesn’t seem to be a solution to me.

Not desperation. I think it’s more “responding to outlandish claims”

Perhaps you need someone else to help you set it up as you seem to be
having some issues getting a reliable solution going using FCGI. None
of us seem to have issues.

I’ve never heard anyone hear discuss these issues, which means a lot of people might be losing out on a lot of traffic that could be coming from search engines because of an SEO problem caused by an incompatibility between php-fcgi and Wordpress.

Or, WordPress just needs a patch to change the behavior, if that is
truly the case. WP should not be sniffing the SAPI to determine
behavior, that’s weird, but WP already does a bunch of weird things.

People use WP Supercache with nginx all the time. Perhaps it’s issuing
the wrong redirect header, but it at least works. I don’t remember
what the OP was asking in the beginning but if it doesn’t work then
there is something else going on. If the issue was the wrong type of
redirect being issued, that’s not something that can be fixed by nginx

  • that’s a WP issue. Switching webservers because of that seems a bit
    overkill; I would submit a bug with WP for it, it is small and I would
    think it should be able to get in the next release.