Я использую nginx вместе с fastcgi. Я вижу много ошибок в журналах ошибок
readv() не удалось (104: Соединение resetby peer) при чтении вверх и вниз recv() не удалось (104: Соединение resetby peer) при чтении заголовка ответа от восходящего потока
Я не вижу проблем с использованием приложения. Являются ли эти ошибки серьезными или как избавиться от них.
Я использовал php-fpm в фоновом режиме, и медленные скрипты были убиты после указанного тайм-аута, потому что он был настроен таким образом. Таким образом, скрипты, занимающие дольше указанного времени, будут убиты, а nginx сообщит об ошибке recv или readv, поскольку соединение будет закрыто от двигателя/процесса php-fpm.
Относительно этой ошибки:
readv() failed (104: Connection reset by peer) при чтении upstream и recv() failed (104: Connection reset by peer) при чтении заголовка ответа вверх
был еще один случай, когда я все еще мог видеть это. Быстрый просмотр:
После просмотра журналов ошибок PHP-FPM и включения catch_workers_output = yes в конфигурации пула php-fpm, я обнаружил, что основной причиной в этом случае был фактически модуль amfext (модуль PHP для Flash). Там известная ошибка и исправление для этого модуля, которые могут быть исправлены путем изменения файла amf.c.
После исправления этой проблемы с расширением PHP ошибка выше не была проблемой.
Это очень неопределенная ошибка, поскольку это может означать несколько вещей. Ключ должен посмотреть на все возможные журналы и понять это. В моем случае, который, вероятно, несколько уникален, у меня была рабочая конфигурация nginx + php/fastcgi. Я хотел скомпилировать новую обновленную версию PHP с PHP-FPM, и я сделал это. Причина в том, что я работал на реальном сервере, который не мог позволить себе время простоя. Поэтому мне пришлось обновить и перейти на PHP-FPM как можно плавно.
Поэтому у меня было 2 экземпляра PHP.
Как только я запустил PHP-FPM (PHP 5.3.8) на nginx-vhost, используя сокет-соединение вместо TCP, я начал получать эту восходящую ошибку на любой странице fastcgi, занимающей дольше, чем x минут, независимо от того, использовали ли они FPM или нет. Обычно это страницы, выполняющие большие SELECTS в mysql, которые загружали ~ 2 минуты. Плохо, я знаю, но это из-за дизайна задней части БД.
Что я сделал, чтобы исправить это, добавьте это в мою конфигурацию vhost: fastcgi_read_timeout 5m; Теперь это можно добавить и в глобальных настройках fastcgi nginx. Это зависит от вашей настройки. http://wiki.nginx.org/HttpFcgiModule
Ответ №2. Довольно интересно fastcgi_read_timeout 5m; для меня был установлен один мотив. Однако я все еще получал ошибку в другом vhost, просто запустив phpinfo(); Для меня это было исправлено, скопировав файл php.ini по умолчанию и добавив в него конфигурацию. У меня была старая копия моего php.ini из предыдущей установки PHP. Как только я поместил php.ini по умолчанию из общего доступа и просто добавил в расширения и конфигурацию, которые мне нужны, это решило мою проблему и больше не было ошибок nginx. Readv() и recv() не удалось.
Я надеюсь, что 1 из этих 2 исправлений поможет кому-то.
Также это может быть очень простая проблема - в вашем коде есть бесконечность cicle или бесконечность, пытающаяся подключить внешний хост на вашей странице.
Иногда эта проблема возникает из-за огромных запросов. По умолчанию pm.max_requests в php5-fpm может быть 100 или ниже.
Чтобы решить эту проблему, ее значение зависит от запросов вашего сайта, например 500.
И после перезагрузки службы
sudo service php5-fpm restart
Другие упомянули параметр 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/