De vez em quando, nosso servidor Linux LAMP (usando PHP-FPM, XFS em thin LVM em HW RAID, Centos8) fica inacessível e para de responder a solicitações HTTP(S).
Através do registro centralizado, descobrimos que, nesses casos, a média de carga atinge rapidamente centenas, enquanto mais e mais processos (systemd-journald, processos php, threads xfs/dm do kernel...) entram no estado D. De acordo com iostat e pidstat, a CPU e o disco não são muito carregados, enquanto a média de carga gira em torno de 170, o que é bastante estranho. Na saída do htop/ps, não há um único ou grupo de processos não autorizados que explicariam esse comportamento. São apenas processos padrão que parecem encontrar algum tipo de "obstáculo".
A única outra coisa estranha com o monitoramento de disco é que durante esses eventos de sobrecarga, o iostat relata intermitentemente w_await bastante alto para a partição /var (2500-5000ms, enquanto outras partições como /var/log, /var/lib/mysql geralmente não superam 10ms). Esta partição deve ficar silenciosa na maior parte do tempo, então não está claro por que o iostat relata tempos w_await tão grandes lá.
A única solução é desligar e ligar o servidor.
Isto acontece em dois servidores do mesmo tipo, nunca em outros. Parece ser algum tipo de mau funcionamento da camada FS/bloco/controlador/disco; muitos processos de repente começam a esperar pelo disco ou qualquer outra coisa no kernel, mas de acordo com iotop/iostat, o disco não está fazendo muita coisa.
Existe uma maneira de consultar o driver FS/camada de bloco/controlador do kernel Linux o que exatamente eles estão fazendo com o armazenamento e em nome de qual processo? Ferramentas padrão como iotop/iostat me informam apenas nomes de processos ativos de E/S e atividades de partição de disco, mas não quais processos acessam qual partição de disco e o que exatamente eles estão fazendo lá.
Responder1
Em situações como essa, acho que ajuda a limitar o número de conexões no topo da pilha.
Quando mais de, digamos, 100ativoprocessos estão em execução, eles tropeçam uns nos outros. Eles estão competindo por recursos (CPU, etc). O efeito líquido é quetodosos processos ficam mais lentos, às vezes a ponto de você sentir que a única solução é reinicializar o servidor.
No caso do MariaDB, recomendo ativar o slowlog para que você possa identificar a consulta que está causando maior impacto no sistema. Então acelere. Se quiser ajuda, forneça a consulta, seu Explicar e Criar Tabela. Mais: http://mysql.rjweb.org/doc.php/mysql_análise#slow_queries_and_slowlog
Acelerar algumas consultas provavelmente diminuirá a média de carga de 170 e a E/S, aliviando assim o gargalo.