Анализ сбоев ядра Linux. Заблокированные процессы, IO и непрерывное ожидание

У меня есть многопользовательское приложение ERP, работающее на платформе CentOS 5.5. Аппаратное обеспечение - HP ProLiant DL380 G6. Это была стабильная система в течение прошлого года, но были проблемы на прошлой неделе. Проблема заключается в постепенном повышении нагрузки на систему в течение нескольких часов до уровня 60+. Система остается отзывчивой, но в какой-то момент сторожевой таймер HP ASR запускает и перезагружает сервер.

У меня есть много таких систем на местах, но у меня не было этой конкретной проблемы раньше. Авария произошла четыре раза за последнюю неделю, но я смог отловить ее сегодня утром, прежде чем система перестала отвечать на запросы.

На этот раз я обнаружил, что загрузка системы составляла около 75, но было 14 процессов зомби, которые я не мог убить. PPID были 1, поэтому я знал, что перезагрузка будет в порядке. Интересно, что нижеприведенная выдержка из вывода dmesg содержит сообщения, которых я не видел в предыдущих сбоях. Что означают эти записи? PID соответствуют процессам зомби, которые я не мог убить. in.telnetd это демон Telnet для определенного сеанса пользователя и dbc это экземпляр приложения ERP для каждого пользователя.

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

1 ответ

Решение

Эти сообщения означают, что что-то потребляет весь доступный ввод / вывод. Это происходит либо из-за (а) сбоя аппаратного обеспечения (диск / контроллер / и т. Д.), Который приводит к тому, что доступный ввод-вывод равен 0, либо (б) при наличии процесса (или процессов), использующего весь ввод-вывод.

Виновным может быть не тот процесс, который указан в dmesg. Это была жертва.

Так как я сомневаюсь, что in.telnetd (кроме вопроса: зачем вам вообще когда-либо работал telnetd?), Затрагивает /data, и у вас есть другие системы, которые не сталкиваются с проблемой, я полагаю, что c0d0 плохой или необходимо обновить прошивку.

Запустите на нем программу диагностики HP Insight. В противном случае в следующий раз выясните, можете ли вы запустить iostat, чтобы увидеть, действительно ли диск перегружен.

Другие вопросы по тегам