Connection reset by peer nginx php fpm

Как победить ошибку: «(104: Connection reset by peer) while reading response header from upstream?

Здравствуйте.
Ubuntu 16, FastCGI (Nginx + PHP-FPM), PHP 7.2.

Со вчерашнего дня сайт периодически выдает 502 ошибку, в лог пишет:

2018/09/02 08:41:18 [error] 7016#7016: *7584 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: xx.xxx.xxx.xxx, server: site.com, request: "GET /page/url/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.2-fpm.sock:", host: "site.com"

user www-data; worker_processes auto; worker_rlimit_nofile 65000; timer_resolution 100ms; worker_priority -5; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events < worker_connections 4096; multi_accept on; use epoll; >http < include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; keepalive_timeout 65; reset_timedout_connection on; include /etc/nginx/conf.d/*.conf; include /etc/nginx/vhosts/*/*.conf; client_body_buffer_size 8m; client_max_body_size 128m; open_file_cache max=200000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on; server < server_name localhost; disable_symlinks if_not_owner; include /etc/nginx/vhosts-includes/*.conf; location @fallback < error_log /dev/null crit; proxy_pass http://127.0.0.1:8080; proxy_redirect http://127.0.0.1:8080 /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; access_log off ; >listen 80; listen [::]:80; > >

server < server_name site.com www.site.com; charset UTF-8; index index.php; disable_symlinks if_not_owner from=$root_path; include /etc/nginx/vhosts-includes/*.conf; include /etc/nginx/vhosts-resources/site.com/*.conf; error_log /var/www/httpd-logs/site.com.error.log crit; ssi on; return 301 https://$host:443$request_uri; set $root_path /var/www/www-root/data/www/site.com; root $root_path; gzip on; gzip_comp_level 5; gzip_disable "msie6"; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript; error_log /var/www/httpd-logs/site.com.error.log notice; location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|js|ico)$ < expires 7d; >location / < try_files $uri /index.php?do=$uri; location ~ [^/]\.ph(p\d*|tml)$ < try_files /does_not_exists @php; >> location @php < fastcgi_index index.php; fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f znleha@yandex.ru"; fastcgi_pass unix:/run/php/php7.2-fpm.sock; fastcgi_split_path_info ^((?U).+\.ph(?:p\d*|tml))(/?.+)$; try_files $uri =404; fastcgi_buffers 4 512k; fastcgi_busy_buffers_size 512k; fastcgi_temp_file_write_size 512k; include fastcgi_params; >access_log off; listen 77.222.63.224:80 default_server; listen [2a02:408:7722:54:77:222:63:224]:80 default_server; > server < server_name site.com www.site.com; ssl_certificate "/var/www/httpd-cert/www-root/site.com_le1.crtca"; ssl_certificate_key "/var/www/httpd-cert/www-root/site.com_le1.key"; ssl_ciphers EECDH:+AES256:-3DES:RSA+AES:!NULL:!RC4; ssl_prefer_server_ciphers on; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; add_header Strict-Transport-Security "max-age=31536000;"; ssl_dhparam /etc/ssl/certs/dhparam4096.pem; charset UTF-8; index index.php; disable_symlinks if_not_owner from=$root_path; include /etc/nginx/vhosts-includes/*.conf; include /etc/nginx/vhosts-resources/site.com/*.conf; error_log /var/www/httpd-logs/site.com.error.log crit; ssi on; set $root_path /var/www/www-root/data/www/site.com; root $root_path; gzip on; gzip_comp_level 5; gzip_disable "msie6"; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript; error_log /var/www/httpd-logs/site.com.error.log notice; listen [2a02:408:7722:54:77:222:63:224]:443 ssl default_server; listen 77.222.63.224:443 ssl default_server; location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|js|ico)$ < expires 7d; >location / < try_files $uri /index.php?do=$uri; location ~ [^/]\.ph(p\d*|tml)$ < try_files /does_not_exists @php; >> location @php < fastcgi_index index.php; fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f znleha@yandex.ru"; fastcgi_pass unix:/run/php/php7.2-fpm.sock; fastcgi_split_path_info ^((?U).+\.ph(?:p\d*|tml))(/?.+)$; try_files $uri =404; fastcgi_buffers 4 512k; fastcgi_busy_buffers_size 512k; fastcgi_temp_file_write_size 512k; include fastcgi_params; >access_log off; >

Ошибка может появиться в любой момент (может и не появиться). От куда ноги растут, не пойму.
Подскажите, куда копать?
Спасибо.

Источник

Fix Nginx 104: Connection Reset By Peer While Reading Response Header From Upstream

Nginx 502 is an uncommon error that causes due to issue with your server Nginx and PHP-FastCGI. If you notice any Nginx 502 error it is better to check the Nginx log.

When you are investigating the Nginx error logs, you can see that the “recv() failed (104: Connection reset by peer) while reading response header from upstream,” error. This also results in a “no live upstreams while connecting to upstream” error. When I’m checking my WordPress site logs I saw that several times appeared that error log. This is an issue with the Nginx and PHP-FPM configurations. Can easily fix it in just a few steps.

• Nginx and PHP-FPM communication error.
• PHP-FPM is timing out quickly.
• PHP-FPM is not running.

In order to fix 104: Connection reset by peer while reading response header from upstream issue, you should have access to modify the PHP and Nginx configuration files. If you are on shared hosting or a managed hosting package, you can ask your hosting partner to correct that configuration file.

How to Fix Connection Reset By Peer While Reading Response Header From Upstream.

If you can see continuous connection reset by peer error your visitors may receive “502 Bad Gateway” errors. To correct this Nginx error you must set Nginx keepalive_requests and PHP-FPM pm.max_requests equal value. If these two values are not equal then the Nginx or PHP-FPM end up closing the connection. This is an issue caused by server configuration mismatch, you can fix it by like our Logrotate issue guide.

Change Nginx keepalive_requests.

• Change keepalive_requests as per your need. Don’t use too high keepalive_requests, it can cause excessive memory usage.

• Save the configuration file.

• Save the configuration file.
• Restart the Nginx and PHP-FPM by running the following command line.

Check PHP permission for session.save_path.

In some situations, your PHP is not able to write the season file. This will generate Nginx 502 connection reset by peer while reading response header from upstream.

• First check where your PHP session.save_path is. Some situations it is “/var/lib/php/sessions” or “/var/lib/php/session“
• Open your system php.ini file and search for “session.save_path“.
• Then you can see your system PHP session.save_path.
• Run the following command in your SSH terminal to fix the permission issue. In this example my LEMP stack php session.save_path is “/var/lib/php/session“

Change FastCGI Timeouts.

Another solution is to change the Nginx Fast-CGI timeouts. Default FastCGI timeout is the 60s. Your application may require higher than the 60s to run, therefore it is better to change the following timeouts to prevent Nginx 502 bad gateway error.

• Open the nginx configuration file. Generally it is “/etc/nginx/nginx.conf“.
• Change add the following timeout values to your nginx.conf.
  • • fastcgi_read_timeout 300;
    • fastcgi_send_timeout 300;
    • fastcgi_connect_timeout 300;

    Increase opcache memory limit.

    • Open the php.ini file.
    • Search for “opcache.memory_consumption”.
    • Change the value to a higher amount like below.

    Источник

    Как исправить ошибку «recv() failed (104: Connection reset by peer) 502» в php-fpm / nginx?

    Здравствуйте. Имеется сервер fastvps.ru/dedicated тариф EX-4, установлена ОС Debian-70-wheezy-64. Крутится один основной сайт, на связке nginx и php-fpm. Если нагрузить сайт тестом Siege буквально 10 потоками, то в лог начинают валиться ошибки:

    readv() failed (104: Connection reset by peer) while reading upstream
    recv() failed (104: Connection reset by peer) while reading response

    Optcache включен. Помогите разобраться, что не так с конфигами? Судя по всему, дело в php-fpm.

    user www-data; worker_processes 4; pid /var/run/nginx.pid; events < worker_connections 768; >http < sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; proxy_read_timeout 500; proxy_connect_timeout 500; client_max_body_size 100M; server_names_hash_bucket_size 64; include /etc/nginx/mime.types; default_type application/octet-stream; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; gzip on; gzip_disable "msie6"; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; include /usr/local/ispmgr/etc/nginx.domain; >

    Оценить 1 комментарий

    Ошибка возникает, если включить в шаблонизаторе режим постоянной перекомпилировки шаблонов из tpl в php, тоесть при обширной работе с записью/чтением файлов. В статичном режиме шаблонизатора (только чтение) ошибка не лезет вообще. Я понимаю, что время генерации в режиме перекомпиляции должно быть больше, но всё равно ошибки это не нормально я так понимаю.

    Siege разорвал соединение, пока nginx получал данные от php-fpm или что там у тебя в /etc/nginx/conf.d/*.conf;

    Начни с тестов без php, сделай каталог с простым index.html и натрави туда. Если ошибки остались, дело в кол-во обработчиков: 4 процесса по 768 медленнее, чем 1 процесс с 3072 сокетами на современном железе. Подними worker_connections до 2048 хотя бы.

    Далее с backlog
    Через sysctl net.core.somaxconn узнай значение backlog, если оно меньше параметра worker_connections то в sysctl.conf увеличивай до значения = worker_connections
    Такое же значение укажи в fpm listen.backlog

    net.core.somaxconn = 128 у меня. Поднимать? Насчет worker_connections, увеличить до 2048, а worker_processes оставить 4 или уменьшать нужно?

    128 даже для дома, для торрентов маловато бывает. Для сайта конечно поднимай, 4096 смело можно ставить. worker_processes для тестов оставляй 4, но потом ставь 1 и мониторь макс кол-во соединений на 80 порт в секунду. Когда будет в 75% от (worker_connections*worker_processes) поднимешь worker_processes на единицу. Чем меньше worker_processes тем быстрее будет ответ от сервера (вообще там ищется золотая середина под железо и нагрузки на каждый час суток).

    Скажи значение Response time в Siege. И включи slowlog с таймером равным значению Response time округлённый в большую сторону (будет в секундах «s», я надеюсь). Этим попытаемся определить какой скрипт тормозит.
    Так же полезно будет знать нагрузку на проц и файловую систему (top, htop, iotop, bwm-ng)

    В режиме перекомпиляции шаблонов response time 0.36s, число failed 10-15% от общего числа хитов. В боевом режиме без перекомпиляции 0.28s. Число failed = 0. Тестирую с домашнего компьютера, не локально то есть. Не знаю как скорость моего домашнего интернета влияет на repsonse time, но сама генерация внутри php занимает в среднем 0.05 — 0.08s, скрипты легкие, этот показатель давно уже мониторю.

    Есть у меня одна мысль. В режиме перекомпиляции, каждый раз происходит opcache_reset(), что приводит к пересборке сайта я так понимаю и грузит файловую систему.

    Прогнал iotop, в режиме перекомпиляции активность php-fpm от 1% вплоть до 20%. Это нормально? Каждое обращение порядка 10 файлов-шаблонов пишет/читает. В боевом режиме активность десятые проценты.

    Т.е. судя по всему, в боевом режиме если поток людей будет очень большим, 502 ошибку по причине нагрузки на запись в диск я врятли увижу?

    Не должно быть такого поведения, в случаи если одно соединение повисло, до timeout его не разорвёт, единственный вариант если в Siege например timeout = 1. Тогда понятно почему он не дожидается данных

    @CHADo при включенной перекомпиляции ошибка видна не только в siege но и в логах + сам если обновляю в браузере под нагрузкой, частенько код html тупо до конца не грузится (2/3 страницы и обрыв). Если выключить перекомпиляцию все ок.

    Сделал sysctl net.core.somaxconn=4096, поставил один воркер и worker_connections=2048. Установил на сервер локально siage, при 300 одновременных соединений к 127.0.0.1/, если зайти на сайт через браузер, лезет 502 периодически от имени nginx. Более 300 не получается, пишет мол сокетов не хватает. Timeout=1 дефолтный. Это нормально? Подскажите, как число сокетов для теста увеличить, хочу больше подключений попробовать.

    Стоило чуть накрутить эти параметры, как производительность выросла вдвое

    pm.max_children = 20
    pm.max_spare_servers = 13

    Увеличивай backlog, nofiles (системный для каждого процесса) и кол-во обработчиков в php-fpm (то что начинается с pm.). Таймаут в 1 сек по умолчанию нормально для шустрых сайтов. Так твой сайт не быстрый, но строчек в логах про разорванное соединение будет много, но браузер через десяток секунд всё же отобразит страницу.
    —
    Не все люди любят медленную загрузку, лучше быстрый кастомный 502 с редикректом через N секунд

    Источник