verificar qual processo estava causando o problema de alta carga cpu

0

Estou executando o servidor nginx wordpress no KVM usando o servidor x64 12.04. Foi correndo muito bem cerca de 4 meses até 2 horas atrás. Descobri que meu site está inativo e que não há resposta de ping. Virt-manager registrou alta carga cpu (plz veja a imagem abaixo) antes do desligamento inesperado. Eu quero saber qual processo causou o desligamento inesperado. Os seguintes arquivos de log me fazem pensar que meu servidor está sendo atacado. Qualquer sugestão e ajuda seria apreciada.

kern.logesyslogmostraram-meomesmoresultado.

Nov1103:54:11wwwkernel:[1344541.156239][BLOCOUFW]IN=eth0SAÍDA=MAC=SRC=0.0.0.0DST=224.0.0,1LEN=32TOS=0x00PREC=0xC0TTL=1ID=0DFPROTO=2

Nov1103:54:11wwwkernel:[1344541.156315][BLOCOUFW]IN=eth0OUT=MAC=SRC=0101:080a:2334:c900:0100:0000:0000:0000DST=ff02:0000:0000:0000:0000:0000:0001LEN=72TC=0HOPLIMIT=1FLOWLBL=0PROTO=TIPOICMPv6=130CODIGO=0

/nginx/access.logmemostrou

119.235.237.17--[11/Nov/2012:03:45:29+0900]"GET / blog HTTP / 1.1" 200 30493 "-" "Yeti / 1.0 (NHN Corp .; link )" meu-servidor-ip - - [11 / Nov / 2012: 11: 05: 30 +0900] "POST /wp-cron.php?doing_wp_cron=13 HTTP / 1.0" 499 0 "-" "WordPress / 3.4.2; link "

Servidor ligado aqui. 119.235.237.16 - - [11 / Nov / 2012: 11: 05: 30 +0900] "GET / blog HTTP / 1.1" 200 32935 "-" "Yeti / 1.0 (NHN Corp .; link )"

    
por linuxk 11.11.2012 / 04:46

1 resposta

1

Embora o acesso à web possa ser uma coincidência, é certamente possível que o navegador da Web coreano Crawler criou um Denial Of Service (DOS) não intencional contra o seu site, rastreando-o agressivamente. Isso pode potencialmente falhar nginx ou seu sistema operacional, ou pode apenas torná-los muito lentos para responder de forma eficaz para novos pedidos.

Usar um testador de carga de website pode ajudar a determinar o quanto de carga seu site pode manipular, e talvez reproduzir, se uma carga pesada poderia de fato causar problema para o seu servidor. Dependendo do detalhe fornecido pelo testador de carga, você pode ser capaz de determinar se há alguma melhoria que você possa fazer ao código do seu site ou configuração para melhorar a resposta.

Você também pode escolher apenas bloquear o Web client ofensor ou criar / modificar seu arquivo local robots.txt para bloquear um rastreador específico (por exemplo, o Yeti) ou especificar que parte do seu site eles não deve rastrear. Desculpe ouvir nos seus comentários, mas aparentemente o Yeti não é honrando seu arquivo robots.txt, portanto, bloquear seu intervalo de IPs parece razoável.

    
por Lars Rohrbach 13.11.2012 / 04:55