← На главную

Многие системные администраторы сталкиваются с ситуацией, когда терминальный сервер на базе Windows Server 2008 R2 внезапно начинает потреблять от 50% до 100% ресурсов процессора. Проблема усугубляется тем, что высокая нагрузка происходит скачками, даже когда пользователи отсутствуют в системе. Проанализируем типичную ситуацию: сервер используется для работы в 1С (например, 1С:Управление торговлей в файловом варианте), настроены регламентные задания для выгрузки на сайт, а в журнале событий наблюдается шквал ошибок аудита и постоянный запуск скрипта usrlogon.cmd. Разберем по шагам, почему это происходит и как вернуть сервер в нормальное рабочее состояние.

Шаг 1. Анализ и блокировка брутфорс-атак по RDP

Одной из главных причин описанной картины является подбор паролей (брутфорс) к открытому наружу порту RDP. Злоумышленники используют автоматизированные скрипты, которые пытаются авторизоваться под разными именами пользователей.

Рассмотрим подробнее, как это влияет на систему:

1. Переполнение журнала безопасности (Security Log): Каждая неудачная попытка входа фиксируется в журнале Windows. Когда количество попыток достигает тысяч в минуту, служба журнала событий начинает потреблять значительные ресурсы CPU на запись и индексацию логов на диске.
2. Отработка скрипта usrlogon.cmd: Этот системный скрипт запускается при инициализации терминальной сессии. При агрессивном брутфорсе он может срабатывать в фоновом режиме, вызывая дополнительные скачки нагрузки.
3. Отложенная нагрузка: Даже если вы отключите сервер от интернета, система может продолжать обрабатывать накопленную в оперативной памяти очередь записей аудита или пытаться архивировать переполненный лог, из-за чего процессор не сразу снизит нагрузку.

Как решить проблему: Изменим стандартный порт 3389 на нестандартный, однако помните, что сканеры портов легко находят и открытые нестандартные порты. Настроим нормальный VPN-доступ или используем RD Gateway с сертификатами. Если RDP должен смотреть наружу, обязательно настроим программную защиту. Установим утилиты защиты от брутфорса для Windows (например, IPBan или EvlWatcher), которые автоматически анализируют журнал событий и добавляют IP-адреса атакующих в правила Брандмауэра.

Шаг 2. Разбор проблем с регламентными заданиями и кэшем 1С

В файловом варианте 1С регламентные задания выполняются не отдельным процессом сервера (как в клиент-серверной архитектуре), а в рамках одного из активных клиентских сеансов. В нашем случае задания запускались от имени Администратора.

Выясним причину, почему отключение регламентных заданий не сразу снимает нагрузку:

1. Зависшие сеансы и бесконечные циклы: Из-за сбоев сети или внутренних ошибок базы задание по обмену с сайтом могло войти в бесконечный цикл. Система 1С пытается выполнить объемную выгрузку, зависает, создает временные файлы блокировок и не может их очистить.
2. Поврежденный кэш: Локальный кэш пользователя Администратор (папка `AppData\Local\1C`) может раздуться до гигантских размеров. При любом обращении к базе процессор тратит ресурсы на чтение поврежденного кэша. Попробуем полностью очистить папки кэша этого пользователя.
3. Фрагментация файловой базы данных: При постоянной выгрузке данных файл 1Cv8.1CD сильно фрагментируется. В сочетании с медленной дисковой подсистемой процессор уходит в ожидание ввода-вывода (I/O Wait). Проведем сжатие и реиндексацию базы с помощью утилиты chdbfl.exe и Конфигуратора (Тестирование и исправление). В обсуждаемой ситуации именно реиндексация базы помогла автору снизить нагрузку до 50%.

Шаг 3. Оптимизация журнала регистрации 1С

Проанализируем состояние ЖурналРегистрации рабочей базы. В старых версиях платформы 1С он может разрастаться до огромных размеров (десятки гигабайт в виде множества мелких файлов). Это приводит к жутким тормозам всей системы.

Решение: Регулярно (раз в год или полгода) переносим старые записи журнала в архив или сокращаем его через Конфигуратор. Если детальный лог не требуется для аудита, можно временно снизить уровень регистрации событий или полностью его отключить для выявления источника тормозов.

Шаг 4. Анализ процесса svchost и скрытых угроз

В Диспетчере задач часто можно заметить процесс svchost.exe (или svchost*32), который потребляет все свободные ресурсы. Посмотрим на возможные причины:

1. Служба обновлений Windows (wuauserv): Для Windows Server 2008 R2 характерна проблема, когда агент обновлений зацикливается при поиске связей между тысячами старых патчей. Откроем вкладку Службы и проверим, что скрывается за нагруженным процессом. Временно остановим wuauserv. Если нагрузка упадет — потребуется ручная установка накопительных пакетов обновления или полное отключение службы.
2. Проблемы с WMI (wmiprvse.exe): Скрипты администрирования или сам сервер могут часто опрашивать систему через Windows Management Instrumentation. При повреждении репозитория WMI возникает утечка памяти. Если папка %SystemRoot%\System32\Wbem\Repository весит подозрительно много, репозиторий необходимо сбросить и перестроить.
3. Вредоносное ПО и майнеры: Важно понимать архитектуру: на 64-битной Windows Server 2008 R2 системные процессы svchost.exe должны быть 64-битными и находиться строго в C:\Windows\System32. Если вы видите svchost*32 (32-битный процесс) вне папки SysWOW64 или в каталогах пользователя/Temp — это практически стопроцентный признак вируса (бэкдора или майнера). Используем программы типа Process Explorer, чтобы посмотреть путь к файлу и его командную строку.

Подведение итогов

Высокая нагрузка на процессор в Windows Server 2008 R2 — это редко проблема одного компонента. Для полной стабилизации сервера выполним следующий чек-лист: очистим журнал событий безопасности и защитим сервер от RDP-брутфорса (закроем порт, поднимем VPN, настроим Fail2Ban-аналог), выполним тестирование, исправление и реиндексацию базы 1С, очистим кэш пользователей и старый журнал регистрации 1С. Обязательно проверим процессы svchost.exe на принадлежность к системным службам и при необходимости отключим зависший поиск обновлений Windows. Комплексный подход позволит не только снизить нагрузку, но и предотвратить ее появление в будущем.