Странные зависания сервера

Кончается память, система уходит в своп?
Бэкапы как делаешь?
Если подключиться к серверу ДО зависания, то что будет во время зависания происходить с ssh-сессией?
Попробуй посмотреть free -m и vmstat, когда оно зависнет. Или прямо перед зависанием. (Munin, это хорошо, но, как видно, он перестает рисовать графики, так что первая идея - адский своппинг).

1. Не могу сказать, так как после того как он завис ничего не могу узнать про сервер. Вот картинка по памяти. http://i036.radikal.ru/1303/68/54c0d41a8f72.png

2. Бэекапы делаются стандартной тулзой ISPManager. /usr/local/ispmgr/sbin/pbackup backup 1 - это в кроне висит

3. 1 раз получилось такое, ssh сессия работала, тоесть пробелы\ентеры\^c\^z нажимались, но реакции не было никакой.

4. К сожалению, когда оно зависнет я наврядле смогу к нему подключится, тока если зареннее подрубится и ждать... Завтра попробую.

Какие еще графики нужны?

А ты попробуй раза 3 ручками бэкап запустить. Вдруг зависнет.
Наваяй скрипт, который каждые, скажем, 5 секунд после старта бэкапа будет сливать куда-нибудь, что выдает top, vmstat, free -m и iostat. Тогда что-то может и видно будет. Munin не даст такой точности.

Ставлю на выжирание всей памяти и глухой уход в своп

Я это в первом комментарии написал.

так может вести себя система если iowait очень большой.

рекомендую помониторить iotop -o

Тестить буду ночью. По результатам отпишусь.

А если вырубить своп?

считай мой комментарий «плюсодином» :)

Если вырубить своп, то в дело вступит oomkiller и начнет УБИВАТЬ.
При условии, что проблема действительно в нехватке памяти.

Это я вкурсе, поэтому и спрашиваю, стоит ли выключать своп для того чтобы определить это? Предположим процесс захавал всю память, oom его кильнет, все развиснет, и запишет в лог чо и почему он кильнул.

Вопрос в том, имеет ли это смысл?

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

И система из фриза выходит сама или нужно ребутить? Какой объём swap'а? Попробуйте настроить netconsole, чтобы сообщения от ядра шли на другой сервер, может «отпадывает» жёсткий диск.

18Гб размер свапа.

Сервак нужно ребутить.

В логах есть хоть какие-то записи после момента фриза до момента ребута?

Если http и dns сервера работают, значит они в ОЗУ. Значит, если даже памяти не хватает и идёт свопинг, ядро в состоянии вытаскивать нужные процессы из swap. Возможно, что это происходило бы медленно, и по ssh зайти было бы нельзя (из-за таймаута на авторизацию), но открытая ssh-сесия бы работала.

Думаю, что можно даже не netconsole настраивать, а просто отправку логов средствами syslogd по сети.

В логах вообще все чисто... Сразу после момента фриза - начало загрузки ядра

ssh сессия работает, но я подозрвеваю что просто соединение поддерживается, а не ссш работает.

По мне это симптомы «отпадывания» жёсткого диска. Диска нет поэтому в логи ничего записатся не может, и не может ничего прочитатся — выполнится команды по ssh. Либо контроллер, либо диск глючный и при большой нагрузке перестаёт работать как надо.

По мне это симптомы «отпадывания» жёсткого диска.

скорее backplaine, imho.

Вырубил swap. Просто не получается ввести его в то состояние.

Есть подозрение, что это еще както связано со временем, я начало бэкапов перевел на 2 часа позже. Но не уверен что это дает какойто результат, но 2-3 раза запускаю и нифига не происходит, просто делаются бэекапы, в логах тишина по поводу памяти\дисков.

У меня как раз недавно отвалился контроллер. Система просто ушла в R/O и могла выполнять только те команды, которые закэшировались в памяти. На остальные - input/Output Error. Так что storage тут не при чём 100% :)

А у меня 9 лет назад отпадывал контроллер RAID'а на DNS-сервере. По ssh зайти было нельзя, в ранее открытой ssh-сесии ничего не работало, работал только bind. Основную функцию сервер выполнял. Сообщения об отказе дисковой подсистемы были видны только на физической консоли. Примерно через 6 часов работы в таком режиме (почти дотянул до конца рабочего дня) ядро решило обратиться к swap'у, который был на этом же массиве, и всё закончилось kernel paniс.

Но в dmesg же должно что-то попадать?

Да, но если команды dmesg нет в кеше в ОЗУ, то её не выполнить, чтобы прочитать эти сообщения, поэтому я и советовал настроить netconsole.

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

Да, но если команды dmesg нет в кеше в ОЗУ, то её не выполнить, чтобы прочитать эти сообщения

А да, точно :)