Поэтапное зависание сервера

от перегрева или скачка напряжения перестало бы работать всё сразу.

Не факт. От перегрева часто начинают появляться разнообразные глюки, вылазящие в разных местах и приводящие к очень разнообразным последствиям.

Я подобную картину наблюдал (правда под линуксом), когда внезапно выпал шлейф от единственного жёсткого диска =). Тоже постепенно начали отваливаться разные сервисы, но сетевая подсистема продолжала работать и компьютер пинговался. Может у тебя что-то с диском или соответсвующим контроллером?

> Я подобную картину наблюдал (правда под линуксом), когда внезапно выпал шлейф от единственного жёсткого диска =). Тоже постепенно начали отваливаться разные сервисы, но сетевая подсистема продолжала работать и компьютер пинговался.

Интересно. Как бы это отследить...

Может у тебя что-то с диском или соответсвующим контроллером?

Диски там зеркало с hot-spare, контроллер... Ну по логике - вывалился бы он из гнезда, сервак не загрузился бы после принудительного on-off-on. С дисками тоже самое, отвалились бы все три, опять бы ничего не загрузилось.

Диски там зеркало с hot-spare, контроллер... Ну по логике - вывалился бы он из гнезда, сервак не загрузился бы после принудительного on-off-on. С дисками тоже самое, отвалились бы все три, опять бы ничего не загрузилось.

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

И это, ты смотрел что сыплется в логи во время медленного зависания? Если моё предположение верно, и отвалился контроллер, то в логи должны были тоннами сыпаться ошибки.

> то в логи должны были тоннами сыпаться ошибки.

Не факт. Если умер io, то весь printk будет только на экране.

Не факт. Если умер io, то весь printk будет только на экране.

В линуксе сообщения ядра можно читать напрямую из /proc/kmsg (просто cat /proc/kmsg), во freebsd тоже такое должно быть.

Не может быть http://www.linux.org.ru/view-message.jsp?msgid=4149991 ?

В Gentoo оказался слишком короткий (15 секунд) таймаут для контроллера HDD.

cat /sys/block/sda/device/timeout

> И это, ты смотрел что сыплется в логи во время медленного зависания?

Вообще ничего. За сутки ни единого сообщения, кроме ntpdate. Он продолжал писать в лог что у него всё хорошо вплоть до перезагрузки. Соответственно вариант с отваливанием дисков или контроллера не катит - как бы ntpdate записал эти строчки, если с диском были проблемы?

Вообще ничего. За сутки ни единого сообщения, кроме ntpdate. Он продолжал писать в лог что у него всё хорошо вплоть до перезагрузки. Соответственно вариант с отваливанием дисков или контроллера не катит - как бы ntpdate записал эти строчки, если с диском были проблемы?

Тогда попробуй память протестить. Поставь на ночь крутиться какой-нибудь memtest86+.

мемори лик с последующей смертью сервисов через OOM-killer, например

мемори лик с последующей смертью сервисов через OOM-killer, например

Но ведь тогда бы в логах что-нибудь осело...

> Поставь на ночь крутиться какой-нибудь memtest86+.

Не факт что memtest86+ что-то найдет.

> Не факт что memtest86+ что-то найдет.

Тестили им сервер несколько суток перед установкой на площадку. Врядли в этом дело.

> Тестили им сервер несколько суток

Тестили сервер несколько суток

Тестили несколько суток

несколько суток

омфг...

нужны сообщения с консоли.

Глюки такого рода много встречал. Условия в дц несколько другие(кстати, проверьте температуру воздуха, винтов и процов), да и глюки бывают такие что проявляются раз в месяц.

Бывает и вообще смешное. Как-то раз сервер стал зависать раз в несколько дней. Опытным путём выяснилось что зависает в 8 утра(тачка вне мониторинга ибо не сильно важна). Оказалось что подвешивал hwclock который запускался по крону. Вот такой новый баг в ядро внесли.

> Вот такой новый баг в ядро внесли.

Скорее всего эта не Баг, а глючное железо, которое на нашем IT-рынке очень много. Если брать брендовый сервер, например от HP, очень малая вероятность, что он будет подвисать.

Потом ошибки в дистрибутиве... Вроде бы продукты одни те же, а повара разные... ;-))))))

Скорее всего эта не Баг, а глючное железо

это баг который был на http://bugzilla.kernel.org/

Если брать брендовый сервер, например от HP

Админил пул из трёх proliant серверов. Серию уже не помню(не сильно новая, правда). Чего стоил один только выход из строя 100% ILO(шесть штук сменили, проблема типа такой: http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627 ... потом hp признал проблему и только спустя пол года исправил firmware). На одном из серверов 4(!) раза меняли платформу. Месяц назад это чудо умудрилось потерять один процессор. Он исчез из ILO и из видимости ОС. Новый админ сказал что недавно проблема повторилась и с новым сервером.

Что это было?

Deadlock на каком-нибудь редко используемом семафоре или спинлоке. Процессы собрались в очередь на семафор, а его какая-то падла держит и ждёт ещё чего-нибудь, без каких-либо шансов получить.