Error de Nginx + php-fpm "504 Gateway Time-out" con carga casi nula (en un servidor de prueba)

29

Después de depurar durante 6 horas, estoy renunciando a esto: |

Tenemos un nginx + php-fpm + mysql en LAN con casi 100 wordpress (creado y utilizado por diferentes diseñadores / desarrolladores, todos trabajando en la configuración de prueba de wordpres)

Estamos usando nginx sin problemas desde hace mucho tiempo.

Hoy, de repente, nginx comenzó a devolver "504 Gateway Time-out" de la nada ...

Revisé el registro de errores de nginx para un host virtual ...

2010/09/06 21:24:24 [error] 12909#0: *349 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 21:25:11 [error] 12909#0: *349 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 21:25:11 [error] 12909#0: *443 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /info.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 21:25:12 [error] 12909#0: *443 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 22:08:32 [error] 12909#0: *1025 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 22:09:33 [error] 12909#0: *1025 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 22:09:40 [error] 12909#0: *1064 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /info.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 22:09:40 [error] 12909#0: *1064 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 22:24:44 [error] 12909#0: *1313 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 22:24:53 [error] 12909#0: *1313 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"

Cuando ejecuté php-fpm en el puerto 9000 a través del modo TCP, ejecuté "netstat | grep 9000" y noté algo inusual ... (Pegar aquí la salida parcial para facilitar la lectura)

tcp        9      0 localhost:9000          localhost:36094         CLOSE_WAIT  14269/php5-fpm  
tcp        0      0 localhost:46664         localhost:9000          FIN_WAIT2   -               
tcp     1257      0 localhost:9000          localhost:36135         CLOSE_WAIT  -               
tcp     1257      0 localhost:9000          localhost:36125         CLOSE_WAIT  -               
tcp        9      0 localhost:9000          localhost:36102         CLOSE_WAIT  14268/php5-fpm  
tcp        0      0 localhost:46662         localhost:9000          FIN_WAIT2   -               
tcp      745      0 localhost:9000          localhost:46644         CLOSE_WAIT  -               
tcp        0      0 localhost:46658         localhost:9000          FIN_WAIT2   -               
tcp     1265      0 localhost:9000          localhost:46607         CLOSE_WAIT  -               
tcp        0      0 localhost:46672         localhost:9000          ESTABLISHED 12909/nginx: worker
tcp     1257      0 localhost:9000          localhost:36119         CLOSE_WAIT  -               
tcp     1265      0 localhost:9000          localhost:46613         CLOSE_WAIT  -               
tcp        0      0 localhost:46646         localhost:9000          FIN_WAIT2   -               
tcp     1257      0 localhost:9000          localhost:36137         CLOSE_WAIT  -               
tcp        0      0 localhost:46670         localhost:9000          ESTABLISHED 12909/nginx: worker
tcp     1265      0 localhost:9000          localhost:46619         CLOSE_WAIT  -               
tcp     1336      0 localhost:9000          localhost:46668         ESTABLISHED -               
tcp        0      0 localhost:46648         localhost:9000          FIN_WAIT2   -               
tcp     1336      0 localhost:9000          localhost:46670         ESTABLISHED -               
tcp        9      0 localhost:9000          localhost:36108         CLOSE_WAIT  14274/php5-fpm  
tcp     1336      0 localhost:9000          localhost:46684         ESTABLISHED -               
tcp        0      0 localhost:46674         localhost:9000          ESTABLISHED 12909/nginx: worker
tcp     1336      0 localhost:9000          localhost:46666         ESTABLISHED -               
tcp     1257      0 localhost:9000          localhost:46648         CLOSE_WAIT  -               
tcp     1336      0 localhost:9000          localhost:46678         ESTABLISHED -               
tcp        0      0 localhost:46668         localhost:9000          ESTABLISHED 12909/nginx: wo             

Hay muchos pares "CLOSE_WAIT" y "FIN_WAIT2" como se resalta a continuación (en la salida anterior):

tcp     1337      0 localhost:9000          localhost:46680         CLOSE_WAIT  -               
tcp        0      0 localhost:46680         localhost:9000          FIN_WAIT2   -

Tenga en cuenta el puerto 46680 de arriba.

Habilité el registro de errores de consultas lentas de mysql, pero no funcionó.

A partir de ahora reiniciar php5-fpm cada minuto a través de un cronjob (ver el comando a continuación) manteniendo todo funcionando "sin problemas", pero odio el patchwork y quiero resolver esto ...

1 * * * * service php5-fpm restart > /dev/null

Busqué mucho en Google, no obtuve ayuda. Como se mencionó, este es un servidor de prueba en LAN, la carga de la CPU nunca se cruza 0.10 y el uso de memoria también está por debajo del 25% (el sistema tiene 2GB de RAM y un servidor ubuntu instalado). al menos dejar caer una pista.

Gracias de antemano por la ayuda.

-Rahul

(nota: esto es volver a publicar - http://forum.nginx.org/read.php?11,127694 )

Actualización: encontré la respuesta, que se publica a continuación.

rahul286
fuente

Respuestas:

31

Encontré respuesta en mi publicación en el foro nginx: http://forum.nginx.org/read.php?2,127854

La respuesta, en mi caso, es establecer:

request_terminate_timeout=30s

en la configuración de php-fpm (generalmente /etc/php5/fpm/php-fpm.conf)

Tenga en cuenta que también puede usar valores distintos de 30.

Lo usé para que coincida con mi valor en el php.iniarchivo principal que es:

max_execution_time = 30

Gracias a todos. :-)

rahul286
fuente
55
Esta configuración también se puede encontrar en el archivo www.conf. Sin embargo, gracias por la respuesta, esto parece haber funcionado.
eddiemoya
2
Esta es una directiva de nivel de grupo, recibirá un mensaje de error cuando intente ponerlo en la [global]sección php-fpm.conf . Funciona allí solo si también tiene las configuraciones de su grupo allí. También: request_terminate_timeout docs .
tanius
Si esta es la respuesta correcta que REALMENTE NECESITO, este viernes será el mejor de 2015 todavía.
Philip
2
Encontré que poner request_terminate_timeout=30sen mi php-fpm.confarchivo causó un error (111 Conexión rechazada). Cuando lo moví a mi www.confarchivo funcionó.
AJB
En CentOS 7.2 cuando se usa php7, request_terminate_timeout se encuentra en:
/etc/php-fpm.d/www.conf
16

Aquí cómo resolvió mi problema:

realice los siguientes cambios en /etc/nginx/nginx.conf en http {section

proxy_connect_timeout  600s;
proxy_send_timeout  600s;
proxy_read_timeout  600s;
fastcgi_send_timeout 600s;
fastcgi_read_timeout 600s;

y luego reiniciar nginx

/etc/init.d/nginx restart

Vijay Kumar
fuente
2
Sí, eso realmente no parece tener nada que ver con el problema que tiene la persona que hace la pregunta.
HopelessN00b
3
pero por suerte eso es lo que necesitaba :)
luchaninov
Esto no solucionó mi problema, pero me permitió ver el error real en lugar del mensaje de tiempo de espera, lo que me llevó al problema real.
Michael
4

Si está utilizando php 5.3, aumente el retraso.

Si está utilizando php 5.2, aplique el parche para aumentar el tamaño de la acumulación de 128.

Además, use un socket Unix en lugar de un socket TCP. unix: /tmp/php5-cgi.sock (o la ruta relevante)

karmawhore
fuente
Tendría que estar de acuerdo, especialmente con el uso del socket Unix.
Matt
Gracias karmawhore por la respuesta. Encontré una solución en la lista de correo nginx.
rahul286
@ rahul286 que responde? ¡estoy interesado!
breiti
@breiti vea mi respuesta a continuación - serverfault.com/a/179136/17440
rahul286
3

Muchas gracias

request_terminate_timeout = 30s

Funciona perfectamente para mí

pero tuve que insertar la línea en este archivo: "/etc/php5/fpm/pool.d/www.conf", es decir, en la "Sección del trabajador".

PHP 5.3.21-1 - Wordpress 3.5.1

http://php-fpm.org/wiki/Configuration_File

Franck
fuente
¡Tuve una combinación de factores que terminaron causando el error 502 que su receta hizo el truco de magia! ¡Muchas gracias!
Jorge Vicente Mendoza
2

en mi caso (el mismo mensaje de error de nginx), algunos scripts php problemáticos no están terminando de ejecutarse y esperando algo, lo que resulta en que no hay más php5-fpm hijos para que nginx elija.

fijar:

  1. agregar límite de tiempo de ejecución otro lo mencionó en esta publicación. request_terminate_timeout=30s
  2. elevar el número de hijos. y todo funcionó a las mil maravillas. pm.max_spare_servers=16 pm.min_spare_servers=2

ahora todo funcionó a las mil maravillas.

c2h2
fuente
Tenía una solicitud de conexión externa de larga ejecución en mi script php. Busque esas tareas de larga duración y espere un tiempo para ellas.
Ali Nadalizadeh
1

Tuve el mismo problema y lo resolví eliminando completamente Apache:

yum remove httpd

Después de eso, recomiendo volver a probar PHP y NGINX:

/etc/init.d/nginx restart
/etc/init.d/php-fpm restart
Nikolay
fuente
1
Entonces no teníamos apache en nuestro servidor. Me alegra saber su caso, ya que puede ayudarnos en el futuro.
rahul286
0

Para mí, ha ocurrido el mismo problema después de eliminar rabbitmq del servidor. Nada de lo anterior no fue útil, reinstalar todos los módulos php5 resolvió el problema. Tenía Debian 8.2 en ese servidor. La esperanza será útil para alguien.

Cometa Taggart
fuente
-1

Esto también puede ayudar a las personas:

Dependiendo de cuál sea su configuración, debe mirar los parámetros de configuración de fastcgi y php ... en mi caso (estoy usando apache2 + php5-fpm) y el tiempo máximo de ejecución también depende de cuánto tiempo el módulo fastcgi espera respuesta ( -tiempo de inactividad) ...

http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiExternalServer

farinspace
fuente
¿por qué usar apache2? Quiero decir que puedes usar nginx directamente para interactuar con php5-fpm. ¡No es necesario usar Apache cuando tienes nginx!
rahul286
Si está usando nginx, si otros NO están usando nginx, con suerte esto les ayudará. :-) ... me encontré con esta página de búsqueda de Apache 2 + php5-pies por minuto relacionada pregunta
farinspace
Okay. Pensé que estás usando Nginx con Apache para scripts PHP como algunas personas lo usaban en el pasado.
rahul286 22/03/11