Я хотел бы отладить проблему, с которой я столкнулся с сервером Linux (стабильный debian), но у меня заканчиваются идеи, как подтвердить любой диагноз.
Немного предыстории: серверы работают под управлением класса DL160 с аппаратным рейдом между двумя дисками. Они запускают множество сервисов, в основном используя сетевой интерфейс и ЦП. Существует 8 процессоров и 7 «основных» процессов, наиболее требовательных к процессорам, каждый из которых привязан к одному ядру через сродство к процессору. Другие случайные фоновые скрипты никуда не навязываются. Файловая система все время записывает ~ 1,5 Кб / с (в пиковое время увеличивается до 2 Кб / с). Нормальное использование ЦП для этих серверов составляет ~ 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% попаданий в кеш), который, кажется, порождает намного больше потоков во время системных проблем. Днем делает ~ 200кг / с (выбирает) и ~ 10кг / с (записывает).
У хоста никогда не заканчивается память или не происходит подкачки, никаких отчетов об ошибках не обнаруживается.
У нас есть много коробок с одинаковым / одинаковым оборудованием, и все они, кажется, ведут себя именно так, но я не уверен, какая часть неисправна, поэтому, вероятно, не стоит просто брать что-то более мощное и надеяться, что проблема исчезнет.
Сами приложения на самом деле не сообщают ни о чем неправильном при запуске. Я могу безопасно запускать что угодно на том же оборудовании в изолированной среде. Что я могу сделать, чтобы сузить проблему? Где еще мне искать объяснения?
DL160? У вас на машине стоит iLO? Оттуда вы можете дистанционно управлять приставкой и перезагружать, включать или выключать питание. Однако может потребоваться расширенная лицензия. iLO работает на отдельном оборудовании от основной системной платы, поэтому он всегда должен быть доступен, пока к серверу подключен шнур питания. iLO также дает вам доступ к запуску сброса NMI на хосте, а также к регистрации последнего фатального сбоя , что позволяет ограниченное изучение.
Вы также пробовали «прожечь» сервер с помощью MemTest86 + в течение примерно 8 часов (при условии, что вы можете себе позволить такой длительный простой)? Ошибки памяти в Linux иногда проявляются довольно забавно. Этот отчет Oops ссылается на функцию памяти (__pagevec_free ()), которая мощь предполагают плохую ячейку памяти, к которой обращаются очень редко, отсюда и период ожидания между сбоями.
Вы также проверили, что ваш BIOS полностью обновлен от HP?
Помимо этого, скомпилируйте собственное ядро и включите все символы отладки, а также посмотрите несколько HOWTO по использованию KGDB для отладки сбоя ядра. Есть некоторые уловки, которые вы можете использовать, чтобы поймать ядро при его сбое, а затем использовать KGDB, чтобы посмотреть на backstrace и, возможно, выследить некорректную пользовательскую программу или дополнительно идентифицировать ваши аппаратные ошибки.