Nginx – php-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream

centos7nginxphp-fpm

I am stacked with following errors on my site when I test 200 hits per second.

First I received 499 errors

2017-04-09 03:22:45 Error 162.158.79.219 499 GET / HTTP/1.1 0 nginx access

2017-04-09 03:22:45 Error 162.158.79.87 499 GET / HTTP/1.1 0 nginx access

2017-04-09 03:22:45 Error 162.158.78.170 499 GET / HTTP/1.1 0 nginx access

2017-04-09 03:22:45 Error 162.158.78.68 499 GET / HTTP/1.1 0 nginx access

2nd Error start showing 502

2017-04-09 03:22:45 Error 162.158.79.135 502 GET / HTTP/1.1 166 nginx access

2017-04-09 03:22:45 Error 162.158.79.225 502 GET / HTTP/1.1 166 nginx access

2017-04-09 03:22:45 Error 162.158.78.110 502 GET / HTTP/1.1 166 nginx access

2017-04-09 03:22:45 Error 162.158.79.225 502 GET / HTTP/1.1 166 nginx access

and Finally I start receiving php-fpm.sock failed errors

2017-04-09 03:22:45 Error 162.158.79.207 20699#0: *3826365 connect() to unix:///var/www/vhosts/system/playhdpk.top/php-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream nginx error

2017-04-09 03:22:45 Error 162.158.79.207 20695#0: *3826367 connect() to unix:///var/www/vhosts/system/playhdpk.top/php-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream nginx error

2017-04-09 03:22:45 Error 162.158.79.207 20697#0: *3826369 connect() to unix:///var/www/vhosts/system/playhdpk.top/php-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream nginx error

My php-fpm-pool-settings are below, I believe this one is being generating errors may I am wrong

listen.backlog = 65535

;[php-fpm-pool-settings]
pm = dynamic
pm.max_children = 5000
pm.start_servers = 50
pm.min_spare_servers = 20
pm.max_spare_servers = 70
pm.max_requests = 2000

My nginx conf are below

user  nginx;
worker_processes 8;

# number of file descriptors used for nginx
# the limit for the maximum FDs on the server is usually set by the OS.
# if you don't set FD's then OS settings will be used which is by default 2000
worker_rlimit_nofile 99999;

error_log /var/log/nginx/error.log crit;

include /etc/nginx/modules.conf.d/*.conf;

events {

    worker_connections 16192;
    use epoll;
    multi_accept on;
}


http {
    include   mime.types;
    default_type  application/octet-stream;

    open_file_cache max=2048 inactive=20s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 5;
    open_file_cache_errors off;


    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_requests 100000;
    reset_timedout_connection on;
    client_body_timeout 30;
    send_timeout 15;

    client_header_timeout 12;
    proxy_connect_timeout  600s;
    proxy_send_timeout  600s;
    proxy_read_timeout  600s;

    fastcgi_buffers 8 128k;
    fastcgi_buffer_size 256k;
    fastcgi_send_timeout 600s;
    fastcgi_read_timeout 600s;

    types_hash_max_size 2048;

    gzip on;
    gzip_min_length 1000;
    gzip_proxied expired no-cache no-store private auth;
    gzip_types application/x-javascript text/css application/javascript text/javascript text/plain text/xml application/json application/v$
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";


    server_tokens off;

    include /etc/nginx/conf.d/*.conf;
}

Note: Server specifications are below

OS CentOS 7.3

Processor: Intel Xeon E5-1620v2 – 4c/8t – 3.7 GHz/3.9 GH

Sever Ram: 64GB DDR3

Best Answer

If I could downvote the answer from @Artsiom forever, I would.

pm.max_children = 4000 means up to 4K worker processes. If traffic flows in very fast and together with pm.max_requests = 0, the workers are never recycled, the RAM usage will grow indefinitely over time and the server will be in out of memory condition (down, frozen) sooner or later.

PHP-FPM max_children should be raised carefully and gradually while monitoring swap usage.

You can use a formula liks the following:

pm.max_children = ((total RAM in MB) - (how much MySQL and others take in RAM)) / 80

Where 80 MB is average weight of a PHP-FPM workers process if your PHP framework is light. For heavy things like Magento 2, take at least 128 MB instead.

And the pm.max_requests should be some "limited" value. In higher spec servers you can indeed raise it (10000, for example), while on low end servers this should be set to smallest (e.g. 500, to even 100) to reduce RAM "usage" fluctuations. But it no scenario I would set it to 0 (unlimited) because a value of 0 implies that your code / PHP and all of its extensions are absolutely free from memory leaks. Only then it would be fine to be set to 0!!!

Related Topic