De vez en cuando, nuestro servidor LAMP de Linux (que usa PHP-FPM, XFS en LVM delgado en HW RAID, Centos8) se vuelve inaccesible y deja de responder a las solicitudes HTTP(S).
A través del registro centralizado descubrimos que en esos casos, el promedio de carga se dispara rápidamente hasta cientos, mientras que cada vez más procesos (systemd-journald, procesos php, subprocesos kernel xfs/dm...) entran en un estado D. Según iostat y pidstat, la CPU y el disco no se cargan mucho, mientras que el promedio de carga ronda los 170, lo cual es bastante extraño. A partir de la salida de htop/ps, no existe ningún proceso único o grupo de procesos no autorizados que pueda explicar este comportamiento. Son sólo los procesos estándar los que parecen encontrar algún tipo de "obstáculo".
La única otra cosa extraña con el monitoreo del disco es que durante esos eventos de sobrecarga, iostat reporta intermitentemente un w_await bastante alto para la partición /var (2500-5000ms, mientras que otras particiones como /var/log, /var/lib/mysql en su mayoría no superan 10 ms). Esta partición debería estar silenciosa la mayor parte del tiempo, por lo que no está claro por qué iostat informa tiempos de espera tan grandes allí.
La única solución entonces es apagar y encender el servidor.
Esto sucede en dos servidores del mismo tipo, nunca en otros. Parece ser algún tipo de mal funcionamiento del FS/capa de bloque/controlador/disco; De repente, muchos procesos comienzan a esperar el disco o algo más en el kernel, pero según iotop/iostat, el disco no está haciendo mucho.
¿Hay alguna forma de consultar el controlador de controlador/capa de bloque/FS del kernel de Linux qué están haciendo exactamente con el almacenamiento y en nombre de qué proceso? Las herramientas estándar como iotop/iostat solo me dicen los nombres de los procesos activos de E/S y la actividad de la partición del disco, pero no qué procesos acceden a qué partición del disco y qué están haciendo exactamente allí.
Respuesta1
En situaciones como esta, encuentro que ayuda a limitar el número de conexiones más arriba en la pila.
Cuando más de, digamos, 100activoLos procesos se están ejecutando, se tropiezan unos con otros. Están compitiendo por recursos (CPU, etc.). El efecto neto es quetodoLos procesos se ejecutan más lento, a veces hasta el punto en que sientes que la única solución es reiniciar el servidor.
En el caso de MariaDB, recomiendo activar el registro lento para que puedas identificar la consulta que está teniendo mayor impacto en el sistema. Entonces acelera. Si desea ayuda, proporcione la consulta, su explicación y creación de tabla. Más: http://mysql.rjweb.org/doc.php/mysql_analysis#slow_queries_and_slowlog
Es probable que acelerar algunas consultas reduzca el promedio de carga de 170 y la E/S, aliviando así el cuello de botella.