2009-11-14 19 views
16

Uso nginx junto con fastcgi. Veo muchos de los siguientes errores en los registros de erroreserrores nginx readv() y recv() fallaron

readv() failed (104: Connection reset by peer) while reading upstream and recv() failed (104: Connection reset by peer) while reading response header from upstream

No veo ningún problema con la aplicación. ¿Son graves estos errores o cómo deshacerse de ellos?

Respuesta

10

Estaba usando php-fpm en segundo plano y las secuencias de comandos lentas se estaban eliminando después de dicho tiempo de espera porque estaba configurado de esa manera. Por lo tanto, las secuencias de comandos que tarden más de un tiempo especificado se matarían y nginx informaría un error recv o readv a medida que se cierra la conexión desde el motor/proceso php-fpm.

+1

¿Alguna vez encontró la manera de obtener realmente un registro de error de PHP o mensaje de esto? – Bretticus

+0

sí php-fpm-slow log. Para habilitar este registro, debe configurar php-fpm.conf – rampr

2

Este es un error muy vago, ya que puede significar algunas cosas. La clave es mirar todos los registros posibles y resolverlo. En mi caso, que es probablemente algo único, tenía una configuración de nginx + php/fastcgi en funcionamiento. Quería compilar una nueva versión actualizada de PHP con PHP-FPM y lo hice. La razón fue que estaba trabajando en un servidor en vivo que no podía permitirse el tiempo de inactividad. Así que tuve que actualizar y pasar a PHP-FPM de la manera más transparente posible.

Por lo tanto, tuve 2 instancias de PHP.

  • 1 hablar directamente con fastcgi (PHP 5.3.4) - utilizando TCP/127.0.0.1:9000 (PHP 5.3.4)
  • 1 configurado con PHP-FPM - utilizando socket Unix - Unix:/dir/al/socket-FPM (PHP 5.3.8)

una vez que empecé a PHP-FPM (PHP 5.3.8) en un host virtual nginx utilizando una conexión de socket en vez de TCP empecé a recibir este error aguas arriba de cualquier página de fastcgi tarda más de x minutos si usaban FPM o no. Normalmente, las páginas que hacían grandes SELECCIONES en mysql tardaban ~ 2 min en cargarse. Lo sé mal, pero esto se debe al diseño de la base de datos back-end.

Lo que hice para solucionarlo fue agregar esto en la configuración de mi vhost: fastcgi_read_timeout 5m; Ahora esto se puede agregar en la configuración de nginx global fastcgi también. Depende de tu configuración. http://wiki.nginx.org/HttpFcgiModule

1

Respuesta # 2. Curiosamente fastcgi_read_timeout 5m; arreglado un vhost para mí Sin embargo, todavía estaba obteniendo el error en otro vhost, simplemente ejecutando phpinfo(); Lo que solucionó esto fue copiando un archivo php.ini de producción predeterminado y agregando la configuración que necesitaba. Lo que tenía era una copia antigua de mi php.ini de la instalación previa de PHP. Una vez que puse el php.ini predeterminado de 'compartido' y acabo de agregar las extensiones y la configuración que necesitaba, esto resolvió mi problema y ya no tuve los errores de nginx que se produjeron los errores readv() y recv().

Espero que 1 de estas 2 soluciones ayude a alguien.

3

respecto a este error:

readv() failed (104: Connection reset by peer) while reading upstream and recv() failed (104: Connection reset by peer) while reading response header from upstream

hubo 1 caso más donde todavía podía ver esto. configuración rápida visión general:

  • CentOS 5.5
  • PHP con PHP-FPM 5.3.8 (compilado a partir de cero con un poco de tercera parte módulos)
  • Nginx 1.0.5

Después de buscar en los registros de errores de PHP-FPM también y permitiendo catch_workers_output = yes en la piscina config php-FPM , Encontré que la causa raíz en este caso era en realidad el módulo amfext (módulo PHP para Flash). Hay a known bug and fix for this module que se pueden corregir alterando el archivo amf.c.

Después de solucionar este problema de extensión PHP, el error anterior ya no era un problema.

0

También puede ser un problema muy simple: hay un infinito en algún lugar de su código, o un infinito tratando de conectar un host externo en su página.

0

Algunas veces este problema ocurre debido a la gran cantidad de solicitudes. Por defecto, el pm.max_requests en php5-fpm puede ser 100 o menos.

Para resolverlo aumentar su valor dependerá de las solicitudes de su sitio Web, por ejemplo 500.

Y después de la que tenga que reiniciar el servicio

sudo service php5-fpm restart 
0

Otros han mencionado el parámetro fastcgi_read_timeout, que se encuentra en el archivo nginx.conf:

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

Además de eso, también tuve t o cambiar la configuración de request_terminate_timeout en el archivo: /etc/php5/fpm/pool.d/www.conf

request_terminate_timeout = 0 

Fuente de información (también hay algunas otras recomendaciones para cambiar los parámetros de php.ini, que puede ser relevante en algunos casos): https://ma.ttias.be/nginx-and-php-fpm-upstream-timed-out-failed-110-connection-timed-out-or-reset-by-peer-while-reading/