Ошибки nginx «recv () завершился ошибкой (104: сброс соединения по одноранговому узлу) при чтении заголовка ответа из восходящего потока»

У меня есть сервер, который работал нормально до 3 октября 2013 года в 10:50, когда он начал периодически возвращать ошибки «502 Bad Gateway» клиенту.

Приблизительно 4 из 5 запросов браузера выполняются успешно, но примерно 1 из 5 завершается с ошибкой 502.

Журнал ошибок nginx содержит много сотен этих ошибок;

2013/10/05 06:28:17 [error] 3111#0: *54528 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 66.249.66.75, server: www.bec-components.co.uk  request: ""GET /?_n=Fridgefreezer/Hotpoint/8591P;_i=x8078 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.bec-components.co.uk"

Однако в журнале ошибок PHP нет соответствующих ошибок.

Есть ли способ заставить PHP дать мне больше информации о том, почему он сбрасывает соединение?

Это nginx.conf;

user              www-data;
worker_processes  4;
error_log         /var/log/nginx/error.log;
pid               /var/run/nginx.pid;

events {
   worker_connections  1024;
}

http {
  include          /etc/nginx/mime.types;
  access_log       /var/log/nginx/access.log;

  sendfile               on;
  keepalive_timeout      30;
  tcp_nodelay            on;
  client_max_body_size   100m;

  gzip         on;
  gzip_types   text/plain application/xml text/javascript application/x-javascript text/css;
  gzip_disable "MSIE [1-6]\.(?!.*SV1)";

  include /gvol/sites/*/nginx.conf;

}

И это .confдля этого сайта;

server {

  server_name   www.bec-components.co.uk bec3.uk.to bec4.uk.to bec.home;
  root          /gvol/sites/bec/www/;
  index         index.php index.html;

  location ~ \.(js|css|png|jpg|jpeg|gif|ico)$ {
    expires        2592000;   # 30 days
    log_not_found  off;
  }

  ## Trigger client to download instead of display '.xml' files.
  location ~ \.xml$ {
    add_header Content-disposition "attachment; filename=$1";
  }

   location ~ \.php$ {
      fastcgi_read_timeout  3600;
      include               /etc/nginx/fastcgi_params;
      keepalive_timeout     0;
      fastcgi_param         SCRIPT_FILENAME  $document_root$fastcgi_script_name;
      fastcgi_pass          127.0.0.1:9000;
      fastcgi_index         index.php;
   }
}

## bec-components.co.uk ##
server {
   server_name   bec-components.co.uk;
   rewrite       ^/(.*) http://www.bec-components.co.uk$1 permanent;
}

я бы всегда доверял, если бы мои веб-серверы говорили мне: 502 Bad Gateway

• Каково время работы вашего fastcgi / nginx - процесса?
• вы контролируете сетевые соединения?
• Можете ли вы подтвердить / опровергнуть изменение количества посетителей в этот день?

что это означает:

• ваш fastcgi-процесс не доступен nginx; либо замедлять, либо не соответствовать вообще. плохой шлюз означает: nginx не может fastcgi_pass к указанному ресурсу 127.0.0.1:9000; в этот особенный момент .

• Ваши исходные журналы ошибок говорят обо всем:

,

recv() failed 
    -> nginx failed

(104: Connection reset by peer) while reading response header from upstream, 
    -> no complete answer, or no answer at all
upstream: "fastcgi://127.0.0.1:9000", 
    -> who is he, who failed???

из моего ограниченного POV я бы предложил:

• перезапустите ваш fastcgi_process / сервер
• проверьте ваш журнал доступа
• включить отладочный журнал

Я знаю, что эта тема старая, но она все еще иногда появляется, поэтому, ища ответы в Интернете, я нашел следующие три возможности:

1. Ошибка программирования иногда приводит к ошибкам php-fpm, что, в свою очередь, означает, что соединение с nginx будет разорвано. Это обычно оставляет по крайней мере некоторые журналы вокруг и / или дампы ядра, которые могут быть проанализированы далее.
2. По какой-то причине PHP не может записать файл сеанса (обычно:) session.save_path = "/var/lib/php/sessions". Это могут быть плохие разрешения, плохое владение, плохой пользователь / группа, или более эзотерические / неясные проблемы, такие как нехватка inode в этом каталоге (или даже полный диск!). Это обычно не оставляет много дампов ядра и, возможно, даже ничего в журналах ошибок PHP.
3. Еще сложнее отлаживать: расширение ведет себя неправильно (время от времени попадая в какое-то внутреннее ограничение, или ошибка, которая не срабатывает постоянно), segfaulting и приводит к остановке процесса php-fpm, закрывая тем самым соединение с nginx. , Обычными виновниками являются APC, memcache / d и т. Д. (В моем случае это было расширение New Relic), поэтому идея в том, чтобы отключить каждое расширение, пока ошибка не исчезнет.

Продолжал получать это также. Решил это путем увеличения opcacheлимита памяти, если вы его используете (замена на APC). Кажется, PHP-FPM сбрасывал соединения всякий раз, когда кеш переполнялся. Это также причина, по которой ответ shgnInc исправляет это на короткое время.

Так что найдите файл /etc/php5/fpm/php.ini(или эквивалент в вашем дистрибутиве) и увеличьте memory_consumptionдо того уровня, который нужен вашему сайту. Отключение opcacheтакже может работать.

[opcache]
opcache.memory_consumption = 196 

Вы можете рассмотреть этот git на github: https://gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209

Я столкнулся с подобной ситуацией, когда я проверял журналы ошибок для моих вышестоящих серверов, они сообщали о некоторой ошибке ulimit, поэтому я увеличил ее до 1000000 (как на upstream, так и на nginx), и все работало нормально.

В моем случае та же проблема, я просто перезапустить php-fpmслужбу, чтобы она решена.

sudo service php5-fpm restart

Или иногда эта проблема возникает из-за огромного количества запросов. По умолчанию pm.max_requestsв php5-fpm может быть 100 или ниже.

Чтобы решить его, увеличьте его стоимость в зависимости от запросов вашего сайта, например, 500.

И после вы должны перезапустить службу

В моем случае отключение расширения xdebug помогло.

У меня просто была похожая проблема:

Вы подключаетесь к php-fpm через порт 9000. (fastcgi: //127.0.0.1: 9000)

Стандартная конфигурация на Ubuntu на моем сервере:

/etc/php/7.0/fpm/pool.d/www.conf:

listen = /run/php/php7.0-fpm.sock

Вы должны изменить это на:

listen = 0.0.0.0:9000

В моем случае я обновил свой сервер полтора месяца назад, перезаписав мою конфигурацию costom настройками по умолчанию. Теперь перезапустив php-fpm, эта ошибка вступила в силу с задержкой.

Для меня это был сервер, исчерпавший память, и php-fpm был убит убийцей OOM. Решение было увеличить объем памяти сервера.

Для меня это было потому, что php-fpm достигал max_childrenпредела. Журнал php-fpm для рассматриваемого пула указал мне правильное направление

Эта проблема может также возникнуть, если процесс PHP-FPM превышает предел выделенной памяти. Когда это происходит, соединение между NGINX и PHP-FPM разрывается, и NGINX возвращает a 502 Bad Gateway. Ограничение памяти процесса PHP-FPM контролируется memory_limitпеременной. Это можно установить с php_admin_value[memory_limit]помощью файла конфигурации PHP-FPM.

Важно отметить, что ограничение памяти применяется для каждого сценария . С nпроцессами PHP-FPM общее использование памяти может быть до memory_limit * n. Убедитесь, что у вашей машины достаточно места для памяти!