У меня есть многопользовательское приложение 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
Эти сообщения означают, что что-то использует все доступные операции ввода-вывода. Это происходит либо из-за (а) сбоя оборудования (диск / контроллер / и т.д.), что приводит к тому, что доступный ввод / вывод равен 0, либо (б) процесс (или процессы) используют весь ввод / вывод.
Виновный процесс не может быть указан в dmesg. Это была жертва.
Поскольку я сомневаюсь, что in.telnetd (в сторону: зачем вам когда-либо работал telnetd?), Касается / data, и у вас есть другие системы, которые не испытывают этой проблемы, я предполагаю, что c0d0 плохой или прошивку необходимо обновить.
Запустите на нем программу HP Insight Diagnostics. В противном случае в следующий раз, когда это произойдет, посмотрите, можете ли вы запустить iostat, чтобы проверить, действительно ли диск перегружен.