У меня есть гость Debian 6 Xen, которая время от времени засыпает. Случайным образом он просто перестает отвечать на любые сетевые запросы (HTTP, ssh, ping) и возобновляет активность только тогда, когда мы авторизуемся на консоли. Сервер явно не разбился, однако во время этого спать когда не происходит никаких действий, даже все журналы (syslogd и klogd) остаются пустыми в это время.
В зависимости от того, когда это произойдет и когда мы действительно сможем войти в консоль, в этом режиме можно потратить несколько минут, а иногда и час. Такое поведение случается нерегулярно, примерно раз в месяц, случайным образом.
У меня нет доступа ни к консоли, ни к хосту Xen, но служба поддержки хостинговой компании сообщает, что ничего подозрительного не показано. Они говорят, что это единственный гость в их инфраструктуре, демонстрирующий такое поведение.
Гость работает под управлением ядра linux 2.6.29.6, скомпилированного хостинговой компанией, имеет 2 ядра, 4 ГБ оперативной памяти и 2 ГБ подкачки. Средняя загрузка за 5 минут не является низкой (от 2 до 3, с пиками до 5), но активность подкачки низкая (подкачка / подкачка), а пространство подкачки почти не используется. Сообщения ядра не обнаруживаются ни в журналах, ни в выводе dmesg.
На этом сервере работают обычные apache + mod_php и proftpd, на самом деле ничего особенного. AFAICT мы не настраивали какие-либо параметры ядра, связанные с часами (однако я не уверен, как я могу проверить настройку ядра, активирован ли режим энергосбережения или пошаговое изменение тактовой частоты).
Нам не хватает подсказок, откуда взялась проблема.
Редактировать: Я бегал find /var -mmin -beforeevent -mmin +afterevent чтобы попытаться найти какой-либо файл, который изменялся во время последнего зависания сервера, и все, что сообщалось о находке, было изменением файла непосредственно до или сразу после события, но ничего между ними, даже если это было 1 час зависания. У этого сервера есть только один раздел, поэтому не работает только диск, содержащий / var.
У меня также есть другие хосты в той же подсети, и все видят, что этот сервер отключен: опрос snmp завершается неудачно, и никакие запросы не регистрируются на хосте БД от любого приложения PHP, запущенного на спать сервер.
Мы также попытались настроить некоторую cronjob для непрерывной активности (например, непрерывной проверки связи с каким-либо другим хостом), что не помешало этому серверу войти в этот спать Режим.
Как бы то ни было, я подозреваю, что эта проблема была связана с нет ntp использование в виртуальной машине. Время виртуальной машины отошло от времени хоста и, вероятно, заставило сервер перейти в спящий режим.
После установки и использования ntpd других подобных инцидентов у меня не было. Однако у меня больше нет этого точного сервера, и я не работал с включенным ntp в течение очень долгого времени (всего 2 или 3 месяца). Отсюда причина, по которой я не могу сказать, что это было само решение этой проблемы.