Hello!

On Mon, Feb 22, 2010 at 12:20:26PM +0100, Vicente Aguilar wrote:

> Hi
>
> >> fastcgi_ignore_client_abort on;
> >> fastcgi_connect_timeout 60;
> >> fastcgi_send_timeout 180;
> >> fastcgi_read_timeout 180;
> > You are ignoring client aborts, and has relatively large timeouts
> > set for fastcgi. Are you sure the connections in question aren't
> > disappear as soon as your fastcgi backend finishes preparing
> > response? I.e. check if any particular connection stay for at
> > least 5 minutes or so.
> >
> > Additionally, check if you are able to reproduce the problem with
> > fastcgi_ignore_client_abort off.
>
> That was my current config which I copied from a site discussing php-fpm. My initial fastcgi config was:
>
> location ~ .php$ {
> # By all means use a different server for the fcgi processes if you need
> # to
> # fastcgi_pass unix:/tmp/php-fastcgi.sock;
> fastcgi_pass 127.0.0.1:9000;
> fastcgi_index index.php;
> fastcgi_param SCRIPT_FILENAME /var/www/$host/$fastcgi_script_name;
> include /etc/nginx/fastcgi_params;
> fastcgi_intercept_errors on;
> }
>
> And also had the problem.

Do you also had CLOSE_WAIT sockets which
fastcgi_ignore_client_abort off?

> > Not responding just because of 100 connections seems strange
> > for nginx even with worker_connections 1024, so I suspect you
> > just run out of php processes and CLOSE_WAIT's are because of
> > fastcgi_ignore_client_abort.
>
> That's what I think too, but there are no stuck PHP connections
> in netstat. Whenever a PHP page is loaded I got some nginx-PHP
> sockets but they all close OK, none gets stuck. Only on the
> client-nginx end is where I can see this behavior with netstat.

By "stuck" you mean sockets in CLOSE_WAIT state? It's expected
that there is no CLOSE_WAIT sockets between nginx and php.

Maxim Dounin

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