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.

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

Strange.

--
Vicente Aguilar <bisente@bisente.com> | http://www.bisente.com_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx