Log - kernel do servidor: INFO: tarefa httpd: 000000 bloqueada por mais de 120 segundos

1

Quase todos os dias, meu servidor está travando devido à alta carga do servidor, e mesmo reiniciar o apache ou o mysql não pode resolver o problema. Eu preciso reiniciar o servidor para resolver, ou ele falhar novamente devido à alta carga.

O sistema de registro registra algo assim quando falha:

Aug 11 18:33:53 server kernel: INFO: task httpd:20008 blocked for more than 120 seconds.
Aug 11 18:33:53 server kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 11 18:33:53 server kernel: httpd         D ffffffff801538ac     0 20008   5816         20066 19809 (NOTLB)
Aug 11 18:33:53 server kernel:  ffff81025a299dc8 0000000000000082 ffff81033b4c0740 ffffffff80009a14
Aug 11 18:33:53 server kernel:  ffff8101063f8d80 0000000000000009 ffff8100b758f7e0 ffff8101c57187e0
Aug 11 18:33:53 server kernel:  00009436d4100b6c 000000000001d50f ffff8100b758f9c8 000000083b531588
Aug 11 18:33:53 server kernel: Call Trace:
Aug 11 18:33:53 server kernel:  [<ffffffff80009a14>] __link_path_walk+0x173/0xfb9
Aug 11 18:33:53 server kernel:  [<ffffffff8002cc16>] mntput_no_expire+0x19/0x89
Aug 11 18:33:53 server kernel:  [<ffffffff80063c4f>] __mutex_lock_slowpath+0x60/0x9b
Aug 11 18:33:53 server kernel:  [<ffffffff80023908>] __path_lookup_intent_open+0x56/0x97
Aug 11 18:33:53 server kernel:  [<ffffffff80063c99>] .text.lock.mutex+0xf/0x14
Aug 11 18:33:53 server kernel:  [<ffffffff8001b21f>] open_namei+0xea/0x712
Aug 11 18:33:54 server kernel:  [<ffffffff8002768a>] do_filp_open+0x1c/0x38
Aug 11 18:33:54 server kernel: Firewall: *UDP_IN Blocked* IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:30:48:9e:6e:99:08:00 SRC=208.43.135.158 DST=255.255.255.255 LEN=151 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=38354 DPT=6112 LEN=131 
Aug 11 18:33:54 server kernel:  [<ffffffff8001a061>] do_sys_open+0x44/0xbe
Aug 11 18:33:54 server kernel:  [<ffffffff8005d28d>] tracesys+0xd5/0xe0

Eu pesquisei muito no Google procurando uma solução. Mas parece que a solução é apenas atualizar o kernel ou driver de disco, acho que não sei como fazer.

Neste URL link , muitas pessoas relatam problemas semelhantes, exceto pelo fato de não serem relacionado ao httpd como o meu.

De acordo com um membro, uma solução seria adicionar "elevator = noop" ao /etc/grub.conf, como neste exemplo:

title CentOS (2.6.18-238.12.1.el5xen)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-238.12.1.el5xen ro root=/dev/VolGroup00/LogVol00 elevator=noop
        initrd /initrd-2.6.18-238.12.1.el5xen.img

Isso realmente resolveria o problema? Meu disco está funcionando no RAID. Isso pode causar algum problema ao meu servidor?

Existe alguma outra solução?

    
por valter 12.08.2011 / 00:41

2 respostas

1

Isso é devido a um bloqueio mutex.

Verifique o rastreamento de pilha impresso com cuidado. Ele vai de cabeça para baixo. Você encontrará esta linha

mutex_lock_slowpath

Parece que há uma crise de recursos.

O Sysstat, como sugerido, é uma boa ferramenta de criação de perfil na maioria dos casos. Se você precisar ir para a raiz do problema, você precisará de um dump de memória do kernel ou vmcore. Existem dois arquivos / proc chamados

/proc/sys/kernel/hung_task_timeout_secs
/proc/sys/kernel/hung_task_panic

O valor do primeiro arquivo é 120. É por isso que você está vendo mensagens de que a tarefa está bloqueada por 120 segundos. Um teste trivial é aumentá-lo e ver o que acontece. Faça 240 ou 360.

O próximo arquivo por padrão tem um valor de 0. Isso precisa ser 1 se você quiser coletar um vmcore.

Obviamente, você precisa configurar o kdump e corrigir o destino do dump. O destino do dump deve ser maior que o tamanho da memória física. Mas mesmo se você coletar o vmcore, você precisará de algum conhecimento de C, assembly e depuração geral para obter um jeito. Um suporte profissional ou sysadmin pode ajudar melhor.

Mas, mudar de elevador não afetará nada aqui.

    
por 26.11.2012 / 11:23
0

Execute uma ferramenta de coleta de estatísticas de desempenho (prefiro sysstat , mas você pode preferir algo diferente) e analise o que está dizendo sobre onde está o afunilamento.

    
por 12.08.2011 / 03:56