Назад | Перейти на главную страницу

Ошибка 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

2-я ошибка начала показывать 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 conf ниже

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 ГГц / 3,9 ГГц

Sever Ram: 64 ГБ DDR3

Если бы я мог навсегда отказаться от ответа от @Artsiom, я бы это сделал.

pm.max_children = 4000 означает до 4K рабочих процессов. Если трафик идет очень быстро и вместе с pm.max_requests = 0, рабочие никогда не перерабатываются, использование ОЗУ будет неограниченно расти с течением времени, и сервер рано или поздно окажется в состоянии нехватки памяти (отключен, завис).

PHP-FPM max_children следует повышать осторожно и постепенно, отслеживая использование свопа.

Вы можете использовать следующую формулу:

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

Где 80 МБ - это средний вес рабочего процесса PHP-FPM, если ваша структура PHP легкая. Для тяжелых вещей вроде Magento 2 возьмите не менее 128 МБ.

И pm.max_requests должно быть какое-то «ограниченное» значение. На серверах с более высокими характеристиками вы действительно можете увеличить его (например, до 10000), в то время как на серверах низкого уровня это должно быть наименьшее (например, от 500 до даже 100), чтобы уменьшить колебания «использования» ОЗУ. Но это не сценарий, я бы установил его на 0 (неограниченно), потому что значение 0 означает, что ваш код / ​​PHP и все его расширения абсолютно свободны от утечек памяти. Только тогда было бы нормально установить 0 !!!

Это происходит потому, что операционная система отклоняет попытки 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-tempoporary-unavailable-459

Не ограничивайте запросы Дайте им работу бесплатно)

pm = ondemand
pm.max_children = 4000
pm.start_servers = 10
pm.min_spare_servers = 10
pm.max_requests = 0