php-fpm.sock 连接上游时失败(11:资源暂时不可用)

php-fpm.sock 连接上游时失败(11:资源暂时不可用)

当我测试每秒 200 次点击时,我的网站上充斥着以下错误。

首先我收到 499 个错误

2017-04-09 03:22:45 错误 162.158.79.219 499 GET / HTTP/1.1 0 nginx 访问

2017-04-09 03:22:45 错误 162.158.79.87 499 GET / HTTP/1.1 0 nginx 访问

2017-04-09 03:22:45 错误 162.158.78.170 499 GET / HTTP/1.1 0 nginx 访问

2017-04-09 03:22:45 错误 162.158.78.68 499 GET / HTTP/1.1 0 nginx 访问

第二个错误开始显示 502

2017-04-09 03:22:45 错误 162.158.79.135 502 GET / HTTP/1.1 166 nginx 访问

2017-04-09 03:22:45 错误 162.158.79.225 502 GET / HTTP/1.1 166 nginx 访问

2017-04-09 03:22:45 错误 162.158.78.110 502 GET / HTTP/1.1 166 nginx 访问

2017-04-09 03:22:45 错误 162.158.79.225 502 GET / HTTP/1.1 166 nginx 访问

最后我开始收到php-fpm.sock failed错误

2017-04-09 03:22:45 错误 162.158.79.207 20699#0: *3826365 connect() to unix:///var/www/vhosts/system/playhdpk.top/php-fpm.sock 失败 (11: 资源暂时不可用) 连接上游 nginx 时出错

2017-04-09 03:22:45 错误 162.158.79.207 20695#0: *3826367 connect() to unix:///var/www/vhosts/system/playhdpk.top/php-fpm.sock 失败 (11: 资源暂时不可用) 连接上游 nginx 时出错

2017-04-09 03:22:45 错误 162.158.79.207 20697#0: *3826369 connect() to unix:///var/www/vhosts/system/playhdpk.top/php-fpm.sock 失败 (11: 资源暂时不可用) 连接上游 nginx 时出错

我的php-fpm-pool-settings如下,我相信这个正在产生错误,我错了

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

我的nginx会议如下

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;
}

笔记:服务器规格如下

操作系统 CentOS 7.3

处理器:Intel Xeon E5-1620v2 - 4c/8t - 3.7 GHz/3.9 GH

服务器内存:64GB DDR3

答案1

如果我可以永远反对@Artsiom 的回答,我会的。

pm.max_children = 4000意味着最多 4K 个工作进程。如果流量非常快,并且pm.max_requests = 0工作进程永远不会被回收,那么 RAM 使用量将随着时间的推移无限增长,服务器迟早会处于内存不足状态(宕机、冻结)。

在监控交换使用情况的同时,应谨慎、逐步地提高 PHP-FPM max_children。

您可以使用如下公式:

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

如果您的 PHP 框架较轻,则 80 MB 是 PHP-FPM 工作进程的平均重量。对于像 Magento 2 这样的重量级框架,请至少使用 128 MB。

而且pm.max_requests应该有一些“有限”的值。在更高规格的服务器上,您确实可以提高它(例如 10000),而在低端服务器上,应该将其设置为最小值(例如 500,甚至 100)以减少 RAM“使用率”波动。但在任何情况下,我都会将其设置为 0(无限制),因为值为 0 意味着您的代码/PHP 及其所有扩展绝对没有内存泄漏。只有这样,设置为 0 才没问题!!!

答案2

发生这种情况是因为操作系统拒绝 nginx 连接到 unix 套接字的尝试。

原因是已经超出了最大套接字连接数或未处理的最大套接字连接数。

检查限制:

sysctl net.core

我们感兴趣的是以下几行:

net.core.somaxconn = 128
net.core.netdev_max_backlog = 200

由于它们,会发生错误,因为最大连接数为 128,最大未处理数为 200

更改限制,在 /etc/sysctl.conf 文件中写入以下行

nano /etc/sysctl.conf

添加

net.core.somaxconn = 20000
net.core.netdev_max_backlog = 65535

应用参数

sysctl -p

重启 php-fpm

service php-fpm restart

来源:https://galaxydata.ru/community/sock-failed-11-resource-temporarily-unavailable-459

答案3

不要限制请求,免费给他们工作)

pm=按需
下午.max_children = 4000
pm.start_servers = 10
pm.min_spare_servers = 10
pm.max_requests = 0

相关内容