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

44

У меня есть сервер, который работал нормально до 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;
}
Найджел Олдертон
источник
Что изменилось в тот день? Обновили ваше приложение или PHP? Какова ваша заявка? Вы включили отладку в php-fpm?
Поти Калимуту
Ничего не изменилось в этот день. Конфигурация сервера не изменилась, равно как и сценарии PHP. Это не из дискового пространства. Мое приложение - это просто набор PHPскриптов. Я не использую php-fpm, я просто бегаю php-fastcgi, делая php-cgi -b 127.0.0.1:9000. Работает без ошибок 3 года. Я не могу понять, почему он разработал эту проблему.
Найджел Олдертон
Недавно у меня была похожая проблема, когда nginx жаловался на сброс соединения по одноранговым узлам при чтении заголовка ответа из апстрима, в моем случае реальная проблема была в uWSGI, перезапуск uWSGI устранил для меня проблему, потому что причина ее возникновения - отдельная вопрос.
APZ
Ваш восходящий сервис ( php-cgi -b 127.0.0.1:9000) периодически дает сбой, возможно, из-за увеличения трафика и нехватки ресурсов.
LinuxDevOps

Ответы:

22

я бы всегда доверял, если бы мои веб-серверы говорили мне: 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 / сервер
  • проверьте ваш журнал доступа
  • включить отладочный журнал
этот парень оттуда
источник
Хорошо. Что мне говорят мои веб-серверы?
Найджел Олдертон
см. мои правки (что это значит)
этот парень оттуда
2
Я вижу, так что Gatewayв данном случае это сервер PHP. Спасибо.
Найджел Олдертон
restart your fastcgi_process / serverэто то, что помогло мне, спасибо
realtebo
11

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

  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), поэтому идея в том, чтобы отключить каждое расширение, пока ошибка не исчезнет.
Гвинет Ллевелин
источник
+1 В моем случае это была №1 - ошибка программирования.
Нимбуз
Мы столкнулись с этой ошибкой, и отключение PHP-расширения New Relic APM выявило более конкретную ошибку, которая позволила нам отследить проблему: [29-Jan-2018 16:47:48 UTC] Неустранимая ошибка PHP: допустимый объем памяти 805306368 байт исчерпан (попытался выделить 262144 байта) в файле vendor / magento / module-configurable-product / Pricing / Price / ConfigurableRegularPrice.php в строке 142 [29-Jan-2018 16:47:48 UTC] Неустранимая ошибка PHP: допустимый объем памяти 805306368 байт исчерпано (попытка выделить 323584 байта) в поле «Неизвестно» в строке 0. Я предполагаю, что «Новая реликвия» задохнулась на пути «Неизвестно».
Эрик Хансен
7

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

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

[opcache]
opcache.memory_consumption = 196 
Мануэль Риэль
источник
2

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

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

AMG Аноним
источник
2

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

sudo service php5-fpm restart

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

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

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

shgnInc
источник
2

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

Василий
источник
Так же, в моем случае я установил условие для точки останова, и в тот момент я отключил точку взлома, ошибка исчезла.
roman204
1

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

Вы подключаетесь к 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, эта ошибка вступила в силу с задержкой.

Фабиан Томмен
источник
1

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

Константин Переяслов
источник
1

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

bruchowski
источник
0

Эта проблема может также возникнуть, если процесс 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. Убедитесь, что у вашей машины достаточно места для памяти!

Фрэнсис
источник