Pregunta ¿Tiempos de espera de Nginx + PHP-FPM, casi cero consumo de carga?


Tengo un servidor que se ejecuta en un Linode con Ubuntu 10.04 LTS, Nginx 0.7.65, MySQL 5.1.41 y PHP 5.3.2 con PHP-FPM.

Hay un blog de WordPress en él, actualizado a WordPress 3.2.1 recientemente.

No he realizado ningún cambio en el servidor (excepto la actualización de WordPress) y, mientras se ejecutaba bien, hace un par de días empecé a tener tiempos de inactividad.

Intenté resolver el problema y, al comprobar el error_log, vi muchos tiempos de espera y mensajes que parecían estar relacionados con los tiempos de espera. El servidor está actualmente registrando este tipo de errores:

2011/07/14 10:37:35 [warn] 2539#0: *104 an upstream response is buffered to a temporary file /var/lib/nginx/fastcgi/2/00/0000000002 while reading upstream, client: 217.12.16.51, server: www.example.com, request: "GET /page/2/ HTTP/1.0", upstream: "fastcgi://127.0.0.1:9000", host: "www.example.com", referrer: "http://www.example.com/"

2011/07/14 10:40:24 [error] 2539#0: *231 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 46.24.245.181, server: www.example.com, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.example.com", referrer: "http://www.google.es/search?sourceid=chrome&ie=UTF-8&q=example"

e incluso vi esta discusión de serverfault anterior Con una posible solución: editar. /etc/php/etc/php-fpm.conf y cambio

request_terminate_timeout=30s

en lugar de

;request_terminate_timeout= 0

El servidor trabajó por algunas horas, y luego se rompió de nuevo. Edité el archivo de nuevo para dejarlo como estaba y reinicié de nuevo php-fpm (service php-fpm restart) pero no hubo suerte: el servidor trabajó durante unos minutos y volvió al problema una y otra vez. Lo extraño es que, aunque los servicios se están ejecutando, htop muestra que no hay carga de CPU (ver imagen) y realmente no sé cómo resolver el problema.

enter image description here

Los archivos de configuración están en pastebin.

los php-fpm.conf el archivo está aquí

los /etc/nginx/nginx.conf  es aquí 

los /etc/nginx/sites-available/www.example.com  es aquí


5
2017-07-14 09:04


origen




Respuestas:


¿Ha intentado en lugar de "upstream" -ing en nginx.conf haciendo algo como:

# Pass PHP scripts to PHP-FPM
location ~* \.php$ {
   try_files       $uri /index.php;
   fastcgi_index   index.php;
   fastcgi_pass    127.0.0.1:9000;
   include         fastcgi_params;
   fastcgi_param   SCRIPT_FILENAME    $document_root$fastcgi_script_name;
   fastcgi_param   SCRIPT_NAME        $fastcgi_script_name;
}

Mira aqui http://www.if-not-true-then-false.com/2011/nginx-and-php-fpm-configuration-and-optimizing-tips-and-tricks/


-1
2018-05-13 09:02



Gracias por el consejo adrian7, en ese momento el problema se resolvió gracias a los consejos del proveedor de alojamiento. Recordaré su punto, no sé si funcionaría, todo está bien ahora, tal vez podría ser útil en situaciones futuras similares a esta. ¡Saludos! - javipas
¿Cuáles fueron los "consejos del proveedor de hosting"? - Daniel T. Magnusson
Me temo que no recuerdo :( De hecho, ese servidor ya no existe. Hace un tiempo moví todo desde allí a otro VPS. ¡Lo siento! - javipas
@ adrian7 Tu sugerencia es absolutamente inútil, ya que no hay diferencia entre fastcgi_pass 127.0.0.1:9000; y upstream backend { server 127.0.0.1:9000; } fastcgi_pass backend;. - VBart


y reinició nuevamente php-fpm [...] el servidor funcionó por unos minutos y regresó al problema una y otra vez

El problema es php-fpm config.

Pero no es el tiempo de espera. Aumentar el tiempo de espera solo le da a PHP más tiempo para procesar una sola solicitud, lo que puede enmascarar los síntomas pero no es la solución correcta.

El registro php-fpm debe hacer que la razón por la que el servidor está teniendo dificultades sea evidente; en mi experiencia (obviamente, en ausencia de información, esto es una conjetura) el archivo de registro php-fpm contendrá entradas como esta:

#/var/log/php5-fpm.log
[19-Oct-2014 06:25:10] NOTICE: error log file re-opened
[19-Oct-2014 17:46:56] WARNING: [pool www] seems busy (you may need to increase
pm.start_servers, or pm.min/max_spare_servers), spawning 1 children, there are 
1 idle, and 5 total children
...

Si solo hay unas pocas entradas de registro como las anteriores, no hay mucho problema. Si hay muchos y solo minutos o segundos de diferencia, entonces php-fpm no tiene recursos suficientes para la carga que se le pide que haga frente.

Esto no es raro porque un archivo de configuración php-fpm de dist estándar contendrá algo similar a esto:

# /etc/php5/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

Lo que significa php-fpm será solo maneja un máximo de 5 peticiones en paralelo.

Especialmente con algo como wordpress, que para una sola página html entrega un gran número de solicitudes posteriores (imágenes, archivos css, js, etc.) también a php: es fácil que se forme una gran cantidad de solicitudes cada vez más grandes para que en cualquier solicitud, primero debe esperar a que se procesen primero las solicitudes en proceso y las que ya están en espera. Esto conlleva retrasos (se mostrará como tiempo de espera en cualquier herramienta de creación de perfiles del navegador) y con frecuencia conlleva un gran número de tiempos de espera.

También tenga en cuenta que un gran número de 404 (solicitudes de cualquier cosa que no existe) es una manera fácil de exagerar las limitaciones de cualquier servidor: verifique y corrija los 404 que genere el sitio.

Como arreglarlo

Si el problema es que php-fpm tiene muy pocos procesos de servidor en ejecución, solo hay que aumentarlos. Los números a usar dependen del hardware del servidor en el que se implementa; He aquí una sugerencia:

# /etc/php5/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 20
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15

Esto permitiría atender 20 solicitudes en paralelo y debería solucionar cualquier problema sin causar problemas al servidor.

Sin embargo, si tiene dudas, hay una regla simple a seguir al cambiar la configuración de php-fpm:

  • Aumente hasta que desaparezcan los mensajes de error (y el rendimiento sea aceptable)
  • Disminuir si el servidor se queda sin memoria o la carga del servidor es inaceptable :)

-1
2017-10-26 16:12



Me temo que el sistema ya no se está ejecutando, por lo que realmente no puedo saber si ese cambio podría hacer que las cosas funcionen como se esperaba. Aunque gracias por tu ayuda. - javipas
Hmm, no estoy seguro. los php5-fpm.log el mensaje que muestra arriba no indica una sobrecarga del servidor, solo una quinta solicitud paralela. Ya que 5 es el máximo. número de procesos secundarios, otras solicitudes luego entrarán en un backlog. A partir de esto, la situación del OP resultaría si los elementos de la cola permanecen durante 3 minutos en ese retraso y el tiempo de espera. Lo que significa, sobrecarga masiva del servidor. Que no es curado por más procesos secundarios de PHP-FPM. Como regla general, estos deben ser aproximadamente el mismo número que los núcleos de CPU en el servidor. - tanius
@tanius la pregunta dice "consumo de carga casi cero": quedarse sin trabajadores no es un indicador de una sobrecarga masiva, solo no poder procesar las solicitudes más rápido de lo que llegan. Solo necesita 1 solicitud lenta y algunos usuarios / solicitudes concurrentes quedarse sin trabajadores. FPM los trabajadores se configuran normalmente en función de la cantidad de memoria libre, no en el caso de la CPU, es decir, los procesos php no están normalmente vinculados a la CPU (esperan las bases de datos, esperan la respuesta de la API, están mal escritas y se esperan a sí mismas ... etc.). OTOH, esta respuesta se basa en un supuesto, al igual que el comentario anterior =). - AD7six
@ AD7six He leído las cosas de nuevo y tienes razón. FPM los trabajadores se configuran en base a mem gratis nginx los trabajadores se configuran de acuerdo con el recuento de núcleos de la CPU (como aquí). Debe haber mezclado las cosas. - tanius