Может помочь дополнительная информация. Как вы определяете "зависание"? Предполагая, что у вас есть физический доступ к серверу, вы можете проверить, какие сообщения ядра появляются на экране после зависания. Требуется ли серверу перезагрузка после остановки?
Вы можете отслеживать обычные системные журналы до момента сбоя в / var / log / messages. Если у вас есть открытый сеанс, когда сервер останавливается, посмотрите сообщения драйвера, запустив dmesg
.
У вас есть какие-либо подробности об оборудовании? Если это оборудование серверного уровня, вы можете проверить журналы оборудования системы, чтобы узнать, есть ли проблемы, такие как плохой ОЗУ и т. Д.
Нет, как правило, нет механизма, который мог бы сказать вам, что именно сломалось, вызвав «зависание».
Пока ваша машина работает, используйте top
для поиска процессов потребляет слишком много ресурсов ЦП, бесплатно
для проверки проблем с памятью (переключение на диск может сделать машину очень-очень-очень медленной) и просматривать файлы просмотра / var / log, чтобы убедиться, что что-то не так.
ps aux | grep Z
отфильтрует зомби-процессы, если они есть.
I got a case open with SuSE where a server freezes. They recommended these steps:
The last helped in my case - but I was able to recrate the problem by triggering a certain action - then I got a Kernel-Debug just before the freeze and with that SuSE was able to provide me a PTF (point-to-fix) Kernel, which removed the problem.
But still you did not describe under which circumstances your problem occurs - in the middle of the night? Never during work?
Чтобы проверить процесс Зомби (несуществующий), мы можем использовать команду.
ps aux|awk '$8 == "Z" {print $0}'
, которая распечатает только процесс, который больше не функционирует.