Ошибка nginx readv () и recv () не удалось - PullRequest
19 голосов
/ 14 ноября 2009

Я использую nginx вместе с fastcgi. Я вижу много следующих ошибок в журналах ошибок

readv () не удалось (104: сброс подключения от сверстников) при чтении вверх по течению и Ошибка recv () (104: сброс подключения peer) при чтении заголовка ответа от вверх по течению

Я не вижу проблем с использованием приложения. Серьезны ли эти ошибки или как от них избавиться?

Ответы [ 8 ]

11 голосов
/ 06 декабря 2009

Я использовал php-fpm в фоновом режиме, и медленные сценарии были убиты после указанного таймаута, потому что он был настроен таким образом. Таким образом, сценарии, занимающие больше заданного времени, будут уничтожены, а nginx сообщит об ошибке recv или readv, когда соединение закрывается из механизма / процесса php-fpm.

4 голосов
/ 03 января 2012

Относительно этой ошибки:

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

был еще один случай, когда я все еще мог видеть это. Обзор быстрой настройки:

  • CentOS 5,5
  • PHP с PHP-FPM 5.3.8 (скомпилирован с нуля какой-то третьей стороной модули)
  • Nginx 1.0.5

Просмотрев журналы ошибок PHP-FPM и включив catch_workers_output = yes в конфигурации пула php-fpm, я обнаружил, что основной причиной в этом случае был модуль amfext (модуль PHP для Вспышка). Известная ошибка и исправление для этого модуля , которые можно исправить, изменив файл amf.c.

После исправления этой проблемы с расширением PHP вышеуказанная ошибка больше не была проблемой.

3 голосов
/ 07 декабря 2011

Это очень расплывчатая ошибка, поскольку она может означать несколько вещей. Ключ должен посмотреть на все возможные журналы и выяснить это. В моем случае, который, вероятно, несколько уникален, у меня был рабочий конфиг nginx + php / fastcgi. Я хотел скомпилировать новую обновленную версию PHP с PHP-FPM, и я сделал это. Причина была в том, что я работал на работающем сервере, который не мог позволить себе простои. Поэтому мне пришлось обновить и перейти на PHP-FPM как можно более плавно.

Поэтому у меня было 2 экземпляра PHP.

  • 1, напрямую говорящий с fastcgi (PHP 5.3.4) - используя TCP / 127.0.0.1:9000 (PHP 5.3.4)
  • 1, настроенный с PHP-FPM - с использованием сокета Unix - unix: / dir / to / socket-fpm (PHP 5.3.8)

После того, как я запустил PHP-FPM (PHP 5.3.8) на хосте nginx с использованием сокетного соединения вместо TCP, я начал получать эту вышестоящую ошибку на любой странице fastcgi, занимая более x минут, независимо от того, использовали они FPM или нет. Как правило, это были страницы, делающие большой выбор в mysql, который загружался ~ 2 минуты. Плохо, я знаю, но это из-за дизайна БД.

Что я сделал, чтобы это исправить, так это добавил это в мою конфигурацию vhost: fastcgi_read_timeout 5m; Теперь это можно добавить и в глобальные настройки fastgin для nginx. Это зависит от вашей настройки. http://wiki.nginx.org/HttpFcgiModule

2 голосов
/ 21 июля 2018

Если вы используете nginx для подключения к php-fpm, одной из возможных причин также может быть значение nginx ' fastcgi_keep_conn , установленное на на (особенно если у вас низкий pm.max_requests настройка в php-fpm):

http|server|location {
    ...
    fastcgi_keep_conn on;
    ...
}

Это может вызвать описанную ошибку каждый раз, когда дочерний процесс php-fpm перезапускается (из-за достижения pm.max_requests ), пока nginx все еще подключен к нему. Чтобы проверить это, установите pm.max_requests в действительно низкое число (например, 1 ) и посмотрите, получите ли вы еще больше вышеперечисленных ошибок.

Исправление довольно простое - просто отключите fastcgi_keep_conn :

fastcgi_keep_conn off;

Или полностью удалить параметр (так как значение по умолчанию off ). Это означает, что ваш nginx будет повторно подключаться к php-fpm при каждом запросе, но влияние на производительность будет незначительным, если вы используете nginx и php-fpm на одной машине и подключаетесь через сокет unix.

1 голос
/ 07 декабря 2011

Ответ № 2. Интересно достаточно fastcgi_read_timeout 5m; исправил один vhost для меня. Однако я все еще получал ошибку в другом vhost, просто запустив phpinfo (); Что я исправил, так это скопировав файл php.ini по умолчанию и добавив в него нужный мне конфиг. У меня была старая копия моего php.ini из предыдущей установки PHP. Как только я добавил php.ini по умолчанию из 'shared' и просто добавил нужные мне расширения и конфиги, это решило мою проблему, и у меня больше не было ошибок nginx: readv () и recv () не удалось.

Я надеюсь, что 1 из этих 2 исправлений кому-нибудь поможет.

0 голосов
/ 12 декабря 2017

Другие упоминали параметр fastcgi_read_timeout , который находится в файле nginx.conf:

http {
    ...
    fastcgi_read_timeout 600s;
    ...
}

Кроме того, мне также пришлось изменить настройку request_terminate_timeout в файле: /etc/php5/fpm/pool.d/www.conf

request_terminate_timeout = 0

Источник информации (есть также несколько других рекомендаций по изменению параметров php.ini, которые могут быть актуальны в некоторых случаях): https://ma.ttias.be/nginx-and-php-fpm-upstream-timed-out-failed-110-connection-timed-out-or-reset-by-peer-while-reading/

0 голосов
/ 10 ноября 2015

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

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

И после этого вам необходимо перезапустить службу

sudo service php5-fpm restart
0 голосов
/ 03 марта 2014

Также это может быть очень простой проблемой - где-то в вашем коде есть бесконечность, или бесконечность пытается подключить внешний хост к вашей странице.

...