Como encontrar a causa do aumento da carga do servidor

12

Estou tendo problemas de carregamento com o meu servidor e, apesar de ser um administrador Linux experiente, estou sem ideias agora.

O problema é uma carga lenta, mas constante, no servidor, sem qualquer causa aparente.

O servidor é um processador AMD Athlon (tm) 64 X2 Dual Core 6000+ com 6 GB de RAM. Está executando o Debian Stable com Linux gir 2.6.26-2-amd64 # 1 SMP Wed Aug 19 22:33:18 UTC 2009 x86_64 GNU / Linux.

O servidor basicamente roda o Lighttpd, vários processos PHP FastCGI e um banco de dados MySQL. Tarefas típicas de servidor da web.

A CPU nunca é realmente totalmente utilizada e a memória é usada principalmente para buffers e cache, o que é bom. Tentei reiniciar os vários serviços para ver se um deles diminuiria a carga novamente, mas sem sorte.

Aqui estão os gráficos que mostram carga, CPU e IOStat:

Então, a pergunta é: o que poderia causar uma carga lenta, mas sempre crescente? E como descubro o que é responsável?

Atualização: esqueci de mencionar que, quando reinicializo o servidor, a carga cairá para cerca de 0,3 a 0,6 e começará a subir novamente lentamente nas próximas semanas.

linux Andreas Gohr
fonte
1
As imagens que você postou não existem mais. Sinta-se à vontade para enviá-los novamente se você ainda tiver cópias.
Michael Hampton

Respostas:

6

Cada processo zumbi adiciona 1,0 à carga. Você pode estar vendo um acúmulo de zumbis.


fonte
Sim. Verifique o gráfico " Número de processos ".
Teddy
Se isso estiver correto, a digitação for N in {1..100} ; do sleep 60 & done ; exec sleep 500deve ser suficiente para causar uma carga alta. Mas isso não acontece. Esse comando produz 100 zumbis, mas a carga no meu computador permaneceu abaixo de 1.
kasperd
5

Encontrei uma excelente dica em resposta a uma pergunta diferente .

A procura de processos no estado 'D' mostra quatro processos PHP que parecem travar por um bom tempo, correspondendo às "etapas" na curva de carga:

#> ps aux | awk '$8 ~ /D/  { print $0 }'
wiki      6651  0.0  0.0      0     0 ?        D    Oct04   0:41 [php-cgi]
bugs      6731  0.0  0.0      0     0 ?        D    Oct27   0:14 [php-cgi]
manpages  7536  0.0  0.0      0     0 ?        D    Oct30   0:21 [php5-cgi]
wiki     23847  0.0  0.0      0     0 ?        D    Oct06   1:32 [php-cgi]

Então, esse parece ser o problema. Agora eu preciso descobrir enquanto esses processos travam e como corrigi-lo. Obrigado a todos.

Andreas Gohr
fonte
Esta resposta resolveu meu problema. A carga aumentou de 0,5 para 350 e continuou subindo. Isso ocorreu devido aos processos zumbis tentando ler uma pasta remota excluída.
Philippe Delteil 26/09/19
2

Meu palpite é que o servidor está passando fome, talvez você deva adicionar as estatísticas do iotop aos gráficos

Gostaria de saber se você pode ter uma atividade por aplicativo io que também é um fator para a carga do servidor

http://rt.wiki.kernel.org/index.php/I/Otop_utility

outra ferramenta é dstat

Mariuz
fonte
Também adicionei gráficos para o IOStat. O IO do disco não aumenta como a carga. É isso que você estava buscando?
Andreas Gohr 03/11/2009
Oh e dstat parece útil. Eu tenho que ler um pouco mais sobre isso.
Andreas Gohr 03/11/2009
2

Se fosse E / S, ele veria o iowait (rosa) nos gráficos da CPU.

3molo
fonte
0

Esse tipo de problema geralmente vem do disco rígido, que não é rápido o suficiente para fornecer dados exigidos pelo banco de dados MySQL e pelo servidor HTTP. Você deve olhar para o comando iostat


fonte
OE parece normal para mim. E isso não explica por que a carga está aumentando lentamente.
Andreas Gohr
-1

Em geral, não é uma coisa ruim ter uma carga alta no servidor; isso significa que você não está sentado ocioso e está fazendo menos do que poderia. A carga total de 80% a 90% da sua capacidade total (com alguma sala "burst") é o que geralmente é procurado. Eu recomendo verificar a saída do mpstat e vmstat. Em particular, os dois primeiros números do vmstat podem fornecer informações mais significativas sobre como você é feito o backup em termos de processos na fila de execução. A última coluna ("wa") da saída vmstat pode informar se, e por quanto tempo, você está aguardando conclusões de E / S. O tamanho da fila de execução e o tempo de espera de E / S são frequentemente correlacionados. Verifique também o sar (do pacote sysstat): que fornece uma visão detalhada do que está acontecendo ao longo de um período de tempo; as métricas que ele registra são muito completas.


fonte