Сегодня мы бы хотели поделиться с вами некоторыми размышлениями на тему того, как решить достаточно распространенную проблему, связанную с зависаниями доменного контроллера. Для примера рассмотрим один типичный случай, который наиболее точно описывает аналогичную ситуацию
Изначально имелся Windows Server 2012 R2, на котором был установлен SQL-Server 2012. Достаточно продолжительное время (примерно год) сервер работал, как надо, но в последнюю неделю начались непонятные зависания. При этом все сетевые ресурсы отключались, а при совершении попыток подключиться по RDP админ мог видеть перед собой только черный экран.
Local не подавал признаков жизни при нажатии комбинации Ctrl+Alt+Delete. При этом невозможно было даже убрать экран блокировки. Если же просмотреть интерфейсы по сети, то они прекрасно пингуются.
Были перепроверены все логи, в которых найти что-то интересное по данной проблеме не представлялось возможным. Сложилось впечатление, что Server наглухо застывал. Перед самим же его «застыванием» в логах можно было увидеть сообщение о том, что лимит по времени ожидания был превышен (30К мс) в процессе ожидания подключенной службы, регистрирующей системные ошибки Windows.
Подобную ошибку можно было встретить до трех раз в течение 10-15 минут (что следует из просмотренных после логов). После этого сервер замирал. Единственным решением данной проблемы казалась кнопочная перезагрузка, после которой в логах можно было видеть только вышеобозначенные сообщения, несколько сообщений о серверном запуска и только.
Куда копать и как можно исправить регулярные зависания Server ?
Возможная утечка памяти
Одной из наиболее вероятных причин в этом отношении могла стать исчерпанная оперативная память на физическом уровне. Для того чтобы определить, так это или нет, в аналогичных ситуациях рекомендуется отследить утечки, связанные с ресурсами физической памяти.
Для этих целей можно использовать такие утилиты, как Task Manager либо Performance Monitor. Кроме того не лишним в данном контексте будет отслеживание динамику, с которой изменяются объемы выделенной виртуальной памяти процессорами наряду с пулами памяти ядра.
Основным подозрительным сигналом в этом случае может служить Memory Pool не подкачиваемый, содержимое которого может сбрасываться в страничные файлы. Однако если страничные файлы ограничены в размерах, либо на диске, где они размещены, слишком мало свободного пространства, то любая утечка памяти из пула подкачки либо в каких-то других процессах вполне могут являться источниками рассматриваемой проблемы.
Возможный сбой в работе системного диска
Вследствие сбоя работы системного диска либо дискового контроллера подобные зависания на сервере также могут иметь место. Если имеется подозрение на наличие такой проблемы, то лучшим решением будет выявить основной характерный для данной ситуации признак, а именно отсутствие в журналах событий каких-либо записей с того момента, как произошло зависание.
При этом если админу каким-то образом удастся просмотреть журнал событий, прежде чем он осуществит перезагрузку, то он обнаружит в логах ряд записей о дисковых сбоях. Стоит учесть, что эти записи не сохранятся на диск и будут утрачены сразу после перезагрузки.
Напоследок хотелось бы отметить один нюанс по поводу DFS-репликации. В событийном журнале фиксируется информация об остановке репликации диска C: вследствие проблем с DFS-базой. Такой исход зачастую является следствием того, что питание компьютера внезапно пропадает, либо пользователь осуществляет перезапуск системы посредством кнопки «Reset».
