У нас есть стандарт сервера 2003 R2 (который я буду называть SRV01), который сейчас немного работает, но он по-прежнему действует как файл, сервер печати и SQL в сети нашей компании. SRV01 содержит профили пользователей, домашние каталоги и почти все наши бизнес-данные. Обратите внимание, что наша AD в настоящее время находится на уровне 2008 R2.
Этот сервер должен быть модернизирован в ближайшие 12 месяцев, но у меня пока нет бюджета, чтобы на него потратить.
Немного истории этого сервера следует:
Когда SRV01 был впервые введен в эксплуатацию, он действовал как контроллер домена (с той же установкой 2003 R2, что и сегодня) в паре с другим сервером, на котором выполнялся Server 2003 R2 SBS.
Несколько лет назад мы приобрели пару выделенных контроллеров домена (2008 R2), и на этом этапе мы списали сервер SBS 2003 года, а SRV01 был удален из AD с помощью DCPROMO.
До недавнего времени SRV01 использовался для запуска Exchange 2003, однако недавно мы приобрели выделенный сервер для Exchange 2010 и обновили его (следуя рекомендованному Microsoft пути обновления). Exchange 2003 был недавно удален. - Чисто, насколько мне известно.
С тех пор, как Exchange был удален из SRV01, я обнаружил, что после нескольких дней безотказной работы, когда я пытаюсь войти в систему, нажатие CTRL-ALT-DEL просто скрывает баннер «Добро пожаловать в Windows Server 2003» и никогда не отображает диалоговое окно входа в систему. Я вижу только подвижный указатель мыши и пустой фон.
Аналогичная история и с сеансом TS администратора, клиент RDP подключается и дает мне пустой фон, но диалоговое окно входа в систему не отображается. Сеанс RDP зависает на неопределенное время, пока я не сдамся и не закрою его.
Единственный способ получить доступ к серверу - отключить его. Хотя на сервере есть резервный контроллер RAID 5 с батарейным питанием, я недоволен тем, что мне пришлось это делать, поэтому в качестве временной меры я создал запланированное задание для перезагрузки SRV01 каждую ночь.
Мне не только не нравится идея запланировать перезагрузку сервера, подобную этой, но она также вызывает проблемы у пользователей, которые оставляют настольные ПК включенными на ночь. Пользователи жалуются на «Отложенные сбои записи», а также был ряд пользователей, которые начали жаловаться на проблемы с блокировкой учетных записей, а также на пользователей, которые не могли подключиться к общим ресурсам на SRV01, пока они не перезагрузили свои настольные ПК.
Я изучил журналы событий на SRV01 и контроллерах домена в поисках подсказок относительно того, в чем проблема, но на самом деле в журнале нет ничего нежелательного. Как я могу исследовать эту проблему, если ничего важного не регистрируется? Можно ли включить дополнительное ведение журнала, которое может дать некоторые подсказки относительно того, что может вызвать эту проблему? Может ли монитор производительности помочь мне в этом, и если да, то какие счетчики вы бы рассмотрели для мониторинга?
Стоит упомянуть, что, хотя сервер не отвечает через консоль и TS, он по-прежнему без проблем реагирует на клиентов, подключающихся к общим ресурсам в течение нескольких дней, но примерно через неделю я начинаю слышать, как пользователи сообщают о проблемах с доступом к общим ресурсам, но это кажется довольно спорадический.
Я также попытался оставить консоль зарегистрированной (и заблокированной), когда я замечаю, что больше не могу войти в систему через TS, я могу разблокировать консоль сервера без проблем, но она отказывается перезагружаться / выключаться, и последующие попытки перезагрузки сообщают, что завершение работы системы уже выполняется, а затем система полностью зависает.
Я пробовал играть в игру ожидания в течение нескольких часов, думая, что тайм-аут может позволить продолжить завершение работы, но безрезультатно.
Я предполагаю, что это x86 (32-бит). Я был бы склонен запустить отладчик Windows при следующем появлении и отобразить объем используемой памяти. В частности, память ядра системы (выгружаемый пул и невыгружаемый пул).
Если у вас есть отладчик Windows, скопированный в папку, запустите windbg.exe и введите следующую команду: !vm
Вы можете обнаружить, что выгружаемый или невыгружаемый пул исчерпан и, возможно, установлен слишком низко. Стандартные настройки памяти ядра в Windows 2003 x86 смехотворно низки и легко истощаются.
Вам также следует убедиться, что в boot.ini не установлен переключатель / 3GB - это только усугубляет проблему истощения памяти ядра.
Это также может указывать на какой-то драйвер-нарушитель, который использует память ядра, например сетевой драйвер.
Если ваш файл подкачки на C: \ достаточно велик, чтобы вместить всю физическую память, вы также можете принудительно запустить синий экран с помощью системных настроек. Полученный дамп памяти можно просмотреть в отладчике. Принуждение к синему экрану полезно, если вы вообще не можете запустить отладчик.
Инструменты отладки для Windows
http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx
Принудительный сбой системы с клавиатуры
http://msdn.microsoft.com/en-us/library/ff545499%28v=vs.85%29.aspx
Я склонен согласиться с тем, что говорит @Greg Askew - это похоже на классический сценарий исчерпания пула памяти ядра.
Я бы выбрал путь использования poolmon.exe инструмент из средств поддержки Windows, а не отладчик. В Windows Server теги пула включены прямо из коробки, а poolmon инструмент довольно прост в использовании. В другом вопросе о сбое сервера Я немного говорю об интерпретации вывода. Мне также повезло с диагностикой этих ситуаций (в частности, с аналогичными утечками) с помощью Анализ производительности журналов инструмент тоже.