Lots of CLOSE_WAIT sockets, nginx+php (WordPress site)

[Vicente Aguilar]

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 at bisente.com> | http://www.bisente.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20100222/6d7cc848/attachment.html>