Connect() to unix:/var/run/php-fpm/php.sock failed

Server NGINX
1

Just finished running a benchmark with http://blitz.io on a development
application written in PHP (using php-fpm with a unix socket, not TCP)
connecting to MySQL. Started with 50 concurrent connections and scaled
up to
250. Got lots of timeouts and errors. In my nginx log, the following is
logged a bunch of times:

2012/10/16 01:28:29 [error] 15019#0: *26418 connect() to
unix:/var/run/php-fpm/php.sock failed (11: Resource temporarily
unavailable)
while connecting to upstream,

What could cause this? I am using nginx 1.2.4 with the following
performance
tweaks:

worker_processes 2;
worker_connections 1024;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 30;
gzip on;
gzip_proxied any;
gzip_comp_level 4;
gzip_disable "msie6";
gzip_types text/plain text/html text/css application/x-javascript

text/xml application/xml application/xml+rss text/javascript
application/javascript application/json

PHP-FPM is configured with 8 static workers and listen.backlog = -1. Any
idea how I can reduce the failures connecting to upstream (PHP-FPM)?

Posted at Nginx Forum:

2

2012/10/16 justin [email protected]

gzip_proxied any;
gzip_comp_level 4;
gzip_disable "msie6";
gzip_types text/plain text/html text/css application/x-javascript

text/xml application/xml application/xml+rss text/javascript
application/javascript application/json

PHP-FPM is configured with 8 static workers and listen.backlog = -1. Any
idea how I can reduce the failures connecting to upstream (PHP-FPM)?

try setting listen.backlog to 128 in FPM configuration. It may be a
bug with listen.backlog = -1 on some FPM version.

++ jerome

3

I set PHP-FPM to:

listen.backlog = 256

and restart PHP-FPM. It was slightly (very little) better, but still:

This rush generated 6,114 successful hits in 1.0 min and we transferred
34.39 MB of data in and out of your app. The average hit rate of
98/second
translates to about 8,476,385 hits/day.

The average response time was 229 ms.

You’ve got bigger problems, though: 10.77% of the users during this rush
experienced timeouts or errors!

Posted at Nginx Forum:

4

Sergey,

Just tried with 50 PHP-FPM workers, and performance was even worse:

This rush generated 5,004 successful hits in 1.0 min and we transferred
47.39 MB of data in and out of your app. The average hit rate of
80/second
translates to about 6,982,940 > hits/day.

The average response time was 276 ms.

You’ve got bigger problems, though: 20.67% of the users during this rush
experienced timeouts or errors!

Same problem logged in /var/log/nginx/error.log:

connect() to unix:/var/run/php-fpm/php.sock failed (11: Resource
temporarily
unavailable) while connecting to upstream

Posted at Nginx Forum:

5

On 16 Oct2012, at 20:56 , justin [email protected] wrote:

Sergey,

Just tried with 50 PHP-FPM workers, and performance was even worse:

Well, if your application is not CPU, i/o etc bound, you have to
find what your php application wait for. In case of php+mysql
it is advisable to enable slow log in php-fpm and mysql.
Sorry but further php debugging you should do yourself -
it is out of scope of the mailing list.

Same problem logged in /var/log/nginx/error.log:

connect() to unix:/var/run/php-fpm/php.sock failed (11: Resource temporarily
unavailable) while connecting to upstream

When 50 php workers serve equal number of requests and another 128
(from listen.backlog) requests wait in backlog, 179th request
will result in “(11: Resource temporarily unavailable) while connecting
to upstream”.

6

connect() to unix:/var/run/php-fpm/php.sock failed (11: Resource
temporarily unavailable) while connecting to upstream

I would suggest you to try switch to tcp - my own experience shows that
communication (even with little speed gain) between nginx and php via
unix
socket is somehow unreliable especially under load.
You have to tweak the backlog and net.core.somaxconn but for me (at
least in
past) even with high values it still produced some percentage of faulty
connections.

rr

7

On 16 Oct2012, at 12:58 , justin [email protected] wrote:

The average response time was 229 ms.
It is simple math: you have 8 php workers, each request take ~ 0.2s,
most of that time request spend in php, so you are able to serve about
40 requests per second. Either increase number of php worker processes
and/or buy new hardware, or tune your php application, use caching and
so on.