Как получить больше информации о сбое системы

Я хотел бы отладить проблему, возникающую у меня с сервером linux (debian stable), но у меня заканчиваются идеи о том, как подтвердить любой диагноз.

Немного предыстории: серверы работают под управлением класса DL160 с аппаратным рейдом между двумя дисками. У них много сервисов, в основном использующих сетевой интерфейс и процессор. Существует 8 процессорных и 7 "основных" процессоров, которые чаще всего потребляют процессор, связаны с одним ядром через процессорство с процессором. Другие случайные фоновые сценарии нигде не используются. Файловая система все время пишет ~1.5k блоков / с (в пиковые моменты времени она поднимается выше 2k/ с). Обычное использование ЦП для этих серверов составляет ~60% на 7 ядрах и некоторое минимальное использование на последних (независимо от того, что обычно работает на оболочках).

На самом деле происходит то, что "основные" сервисы в какой-то момент начинают использовать 100% ЦП, в основном во время работы ядра. Через пару секунд LA переваливает за 400, и мы теряем любой способ подключиться к коробке (KVM уже в пути, но пока нет). Иногда мы видим зависшую задачу ядра (но не всегда):

[118951.272884] INFO: task zsh:15911 blocked for more than 120 seconds.
[118951.272955] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[118951.273037] zsh           D 0000000000000000     0 15911      1
[118951.273093]  ffff8101898c3c48 0000000000000046 0000000000000000 ffffffffa0155e0a
[118951.273183]  ffff8101a753a080 ffff81021f1c5570 ffff8101a753a308 000000051f0fd740
[118951.273274]  0000000000000246 0000000000000000 00000000ffffffbd 0000000000000001
[118951.273335] Call Trace:
[118951.273424]  [<ffffffffa0155e0a>] :ext3:__ext3_journal_dirty_metadata+0x1e/0x46
[118951.273510]  [<ffffffff804294f6>] schedule_timeout+0x1e/0xad
[118951.273563]  [<ffffffff8027577c>] __pagevec_free+0x21/0x2e
[118951.273613]  [<ffffffff80428b0b>] wait_for_common+0xcf/0x13a
[118951.273692]  [<ffffffff8022c168>] default_wake_function+0x0/0xe
....

Это будет указывать на сбой рейда / диска, однако иногда задачи зависают на ядре gettsc что указывало бы на какое-то общее странное поведение оборудования.

Он также запускает mysql (почти только для чтения, 99% попаданий в кеш), который, по-видимому, порождает гораздо больше потоков при системных проблемах. В течение дня он делает ~200kq/s (выбирает) и ~10q/s (пишет).

Хосту никогда не хватает памяти или подкачки, никаких сообщений не обнаружено.

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

Сами приложения на самом деле ничего не сообщают, когда работают. Я могу безопасно запускать что угодно на одном и том же оборудовании в изолированной среде. Что я могу сделать, чтобы сузить проблему? Где еще мне искать объяснения?