Сервер Debian Linux зависает через неделю или около того

У меня есть 2 сервера Debian Linux 6.0.4, которые ведут себя странно: через 5-7-10 дней они зависают. Под этим я подразумеваю, что серверы должны быть перезапущены, и до этого пинг не будет отвечать.

Я боролся с этой проблемой в течение нескольких месяцев, и вот некоторые мысли / то, что я пытался, не имея возможности решить проблему.

  • Я изменил ОЗУ на сервере. Будучи 2-мя разными серверами, я сомневаюсь, что это может быть что-то, связанное с аппаратным обеспечением, поскольку у 3-го идентичного сервера такой проблемы не будет.
  • Я зарегистрировал нагрузку на сервер, и когда он падает, нагрузка в порядке (довольно низкая)
  • Я ничего не могу найти в журналах сервера, журналы в порядке, пока сервер не зависнет.
  • У меня нет доступа к консоли, к сожалению.

Хотя у меня многолетний опыт администратора, я никогда не сталкивался с такой проблемой, и сейчас я понятия не имею, где еще можно провести расследование.

Если у вас есть представление о том, что я могу попробовать, чтобы решить проблему, поделитесь со мной:-)

Источник

3 ответа

Решение

Очевидно, проблема была связана с некоторыми сценариями Python, которые вызывали зависание сервера. Я не понимаю, почему они повесили сервер, но, по крайней мере, они его больше не вешают.

Источник

Пожалуйста, покажите соответствующее содержимое / var / log / messages и / или /var/log/kern.log, возможно, ядро ​​зарегистрировало некоторые отчеты о сбоях или что-то еще, что могло бы пролить некоторый свет. Когда я испытывал такие необъяснимые зависания, это было из-за плохого драйвера, потому что регистрация не очень многословна, я не смог найти точный драйвер.

В моем случае были мягкие блокировки (ядро: [XXXX] BUG: мягкая блокировка - CPU#X). После некоторых исследований я обнаружил http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556030 а последний комментарий дал некоторое представление и способ сделать запись более подробной. Это простая модификация ядра, но если вам неудобно компилировать собственное ядро, это может быть не лучшим решением.

Простое обновление ядра или установка более новой версии и перезагрузка могут решить проблему.

Цитирование:

Мы тщательно исследовали проблему.

Мягкая блокировка TLB flush - только следствие тупика.

Справочная информация: сброс TLB выполняется ЦПУ для ряда других ЦП, используя межпроцессорные прерывания для передачи изменений подкачки. Затем выдающий процессор зацикливается, пока все процессоры не подтвердят изменение. Если такой процессор находится в тупике при спин-блокировке, это никогда не происходит, то срабатывает программная блокировка. Взаимная блокировка возникает при спин-блокировке, иногда эта блокировка может удерживаться кодом пользователя (через интерфейсы модулей /proc или /sys).

Единственный способ определить основную причину (т. Е. Какой драйвер вызывает проблемы) - сбросить ВСЕ стеки ЦП в коде мягкой блокировки.

Один из способов сделать это - модифицировать ядро ​​и добавить

            arch_trigger_all_cpu_backtrace()

в

            kernel/softlockup.c:softlockup_tick()

функция.

Это основано на NMI IPI, который гарантирует, что все стеки сбрасываются, даже в случае тупика (ну и не ожидайте невозможного).

Вы должны легко найти неисправный драйвер и опубликовать соответствующую ошибку.

Источник

Серверы действительно зависают или они просто недоступны с помощью ping?

Установите инструмент мониторинга, такой как Munin (или аналогичный), который покажет вам графики не только нагрузки на процессор, но и статистику памяти, использование диска и различные другие фрагменты - вы можете настроить его для мониторинга множества аспектов. В следующий раз сервер зависает, проверьте графики на наличие каких-либо необычных признаков. Вы узнаете, как выглядит нормальный график, поэтому все необычное подозрительно (хотя и не обязательно неправильно).

Вы уверены, что проверяете все журналы сервера? т.е. есть ли у вас web/mail/ftp/dns/ другие серверы? проверь все такие логи! Не забудьте включить ведение журнала отладки при устранении неполадок.

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

Убедитесь, что вы получаете все системные письма (псевдоним root). Вы даже можете установить OSSEC, который является отличным инструментом для отслеживания журналов и получения электронных писем, когда что-то идет не так. Но этот инструмент OSSEC - просто автоматизированный способ просмотра журналов, так что ничего волшебного.

Проблемы с сетью? Срок аренды аренды истек?

Источник
Другие вопросы по тегам