У меня 2 сервера Debian Linux 6.0.4, у которых странное поведение: через 5-7-10 дней зависают. Под этим я подразумеваю, что серверы необходимо перезапустить, и до этого пинг не ответит.
Я боролся с этой проблемой в течение нескольких месяцев, и вот некоторые мысли / что я пробовал, не имея возможности решить проблему.
Несмотря на то, что у меня есть многолетний опыт администрирования, я никогда не сталкивался с такой проблемой, и сейчас я не знаю, где еще исследовать.
Если у вас есть идея, что я могу попробовать, чтобы решить проблему, поделитесь со мной :-)
Пожалуйста, покажите соответствующее содержимое / var / log / messages и / или /var/log/kern.log, возможно, ядро зарегистрировало какие-то отчеты о сбоях или что-то еще, что может пролить свет. Когда у меня возникли такие необъяснимые зависания, это произошло из-за плохого драйвера, поскольку ведение журнала не очень подробное, я не смог узнать точный драйвер.
В моем случае были мягкие зависания (ядро: [XXXX] BUG: soft lockup - CPU # X). После некоторых исследований я обнаружил http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556030 и последний комментарий дал некоторое понимание и способ сделать ведение журнала более подробным. Это простая модификация ядра, но если вам неудобно компилировать собственное ядро, возможно, это не лучший вариант.
Простое обновление ядра или установка более новой версии и перезагрузка могут решить проблему.
Цитата:
Мы тщательно исследовали проблему.
Мягкая блокировка TLB flush является только ПОСЛЕДСТВИЕМ тупиковой ситуации.
Предпосылки: сброс TLB выдается ЦП ряду других ЦП с использованием межпроцессорных прерываний для прогнозирования изменений подкачки. Затем выдающий ЦП зацикливается, пока все процессоры не подтвердят изменение. Если такой процессор находится в тупике при спин-блокировке, этого никогда не происходит, тогда срабатывает softlockup. Тупик возникает при спин-блокировке, иногда эта блокировка может удерживаться кодом пользователя (через интерфейсы модулей / proc или / sys).
Единственный способ определить основную причину (т.е. какой драйвер вызывает проблемы) - сбросить ВСЕ стеки ЦП в коде мягкой блокировки.
Один из способов сделать это - изменить ядро и добавить
arch_trigger_all_cpu_backtrace()в
kernel/softlockup.c:softlockup_tick()функция.
Это основано на NMI IPI, который гарантирует, что все стеки будут сброшены, даже в случае тупика (не ожидайте, что произойдет невозможное).
Вы должны легко найти неисправный драйвер и опубликовать соответствующую ошибку.
Серверы действительно зависают или они просто недоступны по пингу?
Установите инструмент мониторинга, такой как Munin (или аналогичный), который покажет вам графики не только загрузки процессора, но также статистики памяти, использования диска и различных других элементов - вы можете настроить его для мониторинга множества аспектов. В ближайшее время сервер зависнет, проверьте графики на предмет необычных признаков. Вы научитесь видеть, как выглядит нормальный график, чтобы все необычное выглядело подозрительным (хотя и не обязательно неправильным).
Вы уверены, что проверяете все журналы сервера? т.е. у вас есть web / mail / ftp / dns / другие серверы? проверь все такие логи! Не забудьте включить ведение журнала отладки при устранении неполадок.
Если сервер падает каждую неделю или около того, это может быть что-то, что происходит регулярно, например, задание cron или ротация журналов, и тому подобное.
Убедитесь, что вы получаете все системные электронные письма (корневой псевдоним). Вы даже можете установить OSSEC, который является отличным инструментом для отслеживания журналов и получения сообщений электронной почты, когда что-то идет не так. Но этот инструмент OSSEC - всего лишь автоматизированный способ просмотра журналов, так что ничего волшебного.
Проблемы с сетью? срок аренды dhcp истек?
По-видимому, проблема была связана с некоторыми скриптами Python, из-за которых сервер зависал. Я не понимаю, почему они повесили сервер, но, по крайней мере, они его больше не вешают.