Análise de falha do kernel do Linux. Processos bloqueados, IO e espera ininterrupta

Question

Eu tenho um aplicativo ERP multiusuário em execução em uma plataforma CentOS 5.5. O hardware é o HP ProLiant DL380 G6. Este tem sido um sistema estável para o ano passado, mas tem havido problemas ao longo da semana passada. A questão é um aumento gradual na carga do sistema ao longo de várias horas até níveis de 60+. O sistema permanece responsivo, mas, em algum momento, o temporizador do watchdog ASR HP entra em ação e reinicializa o servidor.

Eu tenho muitos desses sistemas no campo, mas não tive esse problema em particular antes. O acidente ocorreu quatro vezes na semana passada, mas eu consegui pegá-lo esta manhã antes que o sistema não respondesse completamente.

Desta vez, descobri que a carga do sistema era de aproximadamente 75, mas havia 14 processos de zumbis que eu não consegui matar. Os PPIDs eram 1, então eu sabia que uma reinicialização estaria em ordem. Curiosamente, o seguinte é um trecho da saída do dmesg e contém mensagens que não vi em falhas anteriores. O que essas entradas significam? Os PIDs correspondem aos processos zumbis que eu não pude matar. in.telnetd é o daemon Telnet para uma sessão de usuário específica e dbc é a instância do aplicativo ERP por usuário.

INFO: task in.telnetd:12210 blocked for more than 600 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
in.telnetd    D ffff81000102e4a0     0 12210   8899         16297 12762 (L-TLB)
 ffff8103848d7d38 0000000000000046 ffff8108272c1738 ffff81082328ae80
 ffff81082644d9c0 0000000000000009 ffff8102d8d7a080 ffff81011c9df100
 00011ef007c2d74b 0000000000002358 ffff8102d8d7a268 0000000500000001
Call Trace:
 [<ffffffff80063c6f>] __mutex_lock_slowpath+0x60/0x9b
 [<ffffffff8003db0d>] lock_timer_base+0x1b/0x3c
 [<ffffffff80063cb9>] .text.lock.mutex+0xf/0x14
 [<ffffffff8009dc66>] flush_workqueue+0x3f/0x87
 [<ffffffff801a96ee>] release_dev+0x503/0x67b
 [<ffffffff800646f9>] __down_failed+0x35/0x3a
 [<ffffffff80225b40>] sock_destroy_inode+0x0/0x10
 [<ffffffff800537af>] tty_release+0x11/0x1a
 [<ffffffff80012ad9>] __fput+0xd3/0x1bd
 [<ffffffff80023c39>] filp_close+0x5c/0x64
 [<ffffffff80038f19>] put_files_struct+0x63/0xae
 [<ffffffff80015860>] do_exit+0x31c/0x911
 [<ffffffff800491a7>] cpuset_exit+0x0/0x88
 [<ffffffff8005d116>] system_call+0x7e/0x83


INFO: task dbc:9054 blocked for more than 600 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
dbc           D ffff810001036b20     0  9054      1          3272  1795 (L-TLB)
 ffff81028e0c3d38 0000000000000046 0000000000000000 00000000000001d0
 0000000000000000 0000000000000009 ffff8107d60ff100 ffff81011c9ed080
 00011edea224420a 00000000000ebaee ffff8107d60ff2e8 0000000600000000
Call Trace:
 [<ffffffff80063c6f>] __mutex_lock_slowpath+0x60/0x9b
 [<ffffffff8003db0d>] lock_timer_base+0x1b/0x3c
 [<ffffffff80063cb9>] .text.lock.mutex+0xf/0x14
 [<ffffffff8009dc66>] flush_workqueue+0x3f/0x87
 [<ffffffff801a96ee>] release_dev+0x503/0x67b
 [<ffffffff8837dd1d>] :xfs:xfs_free_eofblocks+0x9d/0x1fe
 [<ffffffff800537af>] tty_release+0x11/0x1a
 [<ffffffff80012ad9>] __fput+0xd3/0x1bd
 [<ffffffff80023c39>] filp_close+0x5c/0x64
 [<ffffffff80038f19>] put_files_struct+0x63/0xae
 [<ffffffff80015860>] do_exit+0x31c/0x911
 [<ffffffff800491a7>] cpuset_exit+0x0/0x88
 [<ffffffff8006149d>] sysenter_do_call+0x1e/0x76

    

Answer 1

Essas mensagens significam que algo está consumindo toda a E / S disponível. Isto é devido a (a) falha de hardware (disco / controlador / etc) que resulta na E / S disponível sendo 0 ou (b) havendo um processo (ou processos) usando todas as E / S.

O processo culpado pode não ser o listado no dmesg. Foi a vítima.

Desde que eu duvido in.telnetd (à parte: por que você teria o telnetd rodando?) toques / dados e você tem outros sistemas que não experimentam o problema Eu estou supondo que o c0d0 está ruim ou o firmware precisa ser atualizado .

Execute o HP Insight Diagnostics nele. Caso contrário, da próxima vez que acontecer, veja se você pode executar o iostat para ver se o disco está realmente sobrecarregado.