Alto uso aleatório de CPU no Linux usando o Apache

Question

Recentemente, tive um problema estranho com meu servidor da web. Ao longo do último dia, o site parece estar desacelerando um pouco em intervalos aleatórios, parece que não estamos experimentando nenhum grande tráfego extra, no entanto, uma rápida olhada no 'topo' e httpd parece estar saltando de entre 3-10 % para cerca de 99%, depois batendo por volta dos meados dos anos 80 e depois voltando para baixo. Por exemplo:

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND 
2443 apache    25   0  256m  20m 5472 R 88.2  2.1   3:22.29 httpd

Isso parece acontecer a cada 30 minutos ou mais. O estranho é que, ao mesmo tempo, isso está acontecendo, eu posso rodar a página de status do servidor Apache e obter (por exemplo):

CPU Usage: u700.5 s6.22 cu0 cs0 - 20.2% CPU load

Então, minha pergunta é dupla:

1. Alguém sabe por que esse problema pode ter aparecido no último dia (não houve alterações feitas no servidor)
2. Por que minhas estatísticas de uso da CPU no topo seriam muito maiores do que as do status do servidor e quais estão corretas?

Answer 1

O uso da CPU da página de status do servidor do Apache é o uso médio desde que o Apache foi iniciado, de modo que não mostrará picos como este. Quando você obtiver esses picos de carga, poderá verificar a página de status do servidor para ver quais páginas / clientes estão sendo servidores (ExtendedStatus deve estar ativado).

Você também pode usar o netstat para ver quais clientes estão acessando atualmente sua máquina:

 netstat -an | grep ESTABLISHED

Se você executar isso durante várias horas e picos de tráfego, talvez consiga localizar um endereço IP recorrente e rastreá-lo para um robô / rastreador específico. Se isso acontecer, consulte o robots.txt para limitar a velocidade com que robôs que se comportam devem rastrear seu site.

Editar: Em um servidor ocupado, o comando netstat acima deve mostrar algumas entradas como:

tcp        0      0 10.2.212.13:80              216.146.52.21:24979         ESTABLISHED
tcp        0      0 10.2.212.13:80              86.174.113.138:54901        ESTABLISHED
tcp        0      0 10.2.212.13:80              94.1.216.253:51204          ESTABLISHED
tcp        0      0 10.2.212.13:80              24.9.61.204:62936           ESTABLISHED

O endereço IP do cliente será o da direita. Se você vê apenas 1 ou 2 linhas, isso significa que, naquele momento, existe apenas a conexão ssh. Verifique novamente quando sua carga aumenta. Você também pode remover o grep para listar todas as conexões, embora isso inclua um grande número de TIME_WAIT antigos.

Gostaria de começar com o status estendido do servidor e ver se isso pode revelar rastreadores óbvios durante picos de tráfego.

    

Answer 2

Verifique seus registros de acesso. Você pode ter um dataminer ou rastreador acertando todas as páginas do seu site, já que o intervalo é tão normal.

    

Answer 3

Crie um arquivo executável simples:

#!/usr/bin/sh
# use IP
 netstat -na |grep ESTABLISHED
# use NAMES
# netstat -ta |grep ESTABLISHED

O "ta" irá imprimir os nomes DNS, portanto, descomente o que você preferir.

Em seguida, coloque em um programa que execute arquivos em um intervalo, como um crontab. Eu leria a man page para isso, você pode não ser capaz de usá-la. Você desejará enviar a saída para um log para uso futuro. Você pode adicionar um comando de data ao script se preferir anotar o tempo executado. Exemplo de crontab:

#minute hour dayofmonth monthofyear dayofweek
0,15,30,45 * * * * <path/to/script> > <log>

Isto é editado com crontab -e (leia novamente a página do manual).

Você pode usar isso para classificar as principais entradas em seu access.log:

awk '{print $1}' access_log | sort |uniq -c |sort -n

Se você está realmente vendo uma resposta lenta com a página da web, olhe para a espera de E / S, e algumas vezes o uso da CPU sendo "alto" não é grande coisa.

    

Answer 4

Eu suspeito que você esteja rodando em um processador quad core. Nesse caso, você pode facilmente acabar em uma situação onde top retornará o% como uma carga por núcleo, enquanto outras ferramentas dividiriam esse número pelo número de núcleos para chegar a um total de carga total da CPU.

No que diz respeito às variações, estou inclinado a dar o mesmo conselho que Hyppy.