it-swarm.com.ru

ошибка nginx readv () и recv () не удалось

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

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

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

16
rampr

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

11
rampr

По поводу этой ошибки:

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

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

  • CentOS 5.5 
  • PHP с PHP-FPM 5.3.8 (скомпилирован с нуля с некоторыми сторонними Модулями) 
  • Nginx 1.0.5

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

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

4
Paul G.

Это очень расплывчатая ошибка, поскольку она может означать несколько вещей. Ключ заключается в том, чтобы просмотреть все возможные журналы и выяснить это…. В моем случае, который, вероятно, несколько уникален, у меня была рабочая конфигурация 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

3
Paul Greene

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

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

1
Paul Greene

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

0
Funcraft

Другие упоминали параметр 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-time-out-or-reset-by-peer-while-read/

0
Rauni Lillemets

Если вы используете nginx для подключения к php-fpm, одной из возможных причин может быть также то, что для параметра nginx 'fastcgi_keep_conn установлено значение on (особенно если у вас низкий параметр 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.

0
FoxEcho

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

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

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

Sudo service php5-fpm restart
0
shgnInc