Рассмотрим распространенную и крайне неприятную ситуацию: сервер 1С:Предприятие внезапно начинает потреблять все ресурсы центрального процессора. При анализе через диспетчер задач выясняется, что основным виновником является процесс rmngr.exe (менеджер кластера). Эта проблема парализует работу пользователей, особенно тех, кто использует тонкие клиенты или терминальный доступ. Проанализируем причины такого поведения и разберем по шагам проверенные методы решения.
Процесс rmngr.exe выполняет в системе 1С множество функций: управление сеансами, блокировками, регламентными заданиями и, что самое важное, ведение журнала регистрации. В версиях платформы 8.3 (особенно в ветке 8.3.7 и выше) по умолчанию используется новый формат журнала регистрации — файлы с расширением .lgd, построенные на базе базы данных SQLite.
Как показывает практика и анализ с помощью системных утилит (например, Process Monitor), основная нагрузка зачастую связана именно с непрерывным обращением к этим файлам. Проблема кроется в архитектуре SQLite: при большом количестве записей или интенсивном чтении (отборы, отчеты по журналу) процесс rmngr.exe начинает циклично ожидать доступа к файлу, что выливается в 100% загрузку CPU. Выясним, как с этим бороться.
Это самый эффективный способ, если ваш сервер «захлебывается» от нового формата .lgd. Старый текстовый формат .lgf работает гораздо стабильнее при больших объемах данных и не вызывает таких блокировок процессора. Разберем алгоритм действий по переходу.
Важно: При выполнении этих действий текущая история журнала регистрации в базе станет недоступна через стандартный интерфейс (она останется в старых файлах), и начнется запись нового журнала.
services.msc).C:\Program Files\1cv8\srvinfo\reg_1541\ (где 1541 — порт вашего кластера).xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx). Проанализируем каждый из них.1Cv8Log.1Cv8Log в 1Cv8Log_old. Это позволит нам сохранить старые логи на всякий случай.1Cv8Log.1Cv8Log создадим пустой текстовый файл и переименуем его в 1Cv8.lgf. Наличие этого файла с таким расширением заставит платформу использовать старый формат журналирования.После этого сервер начнет писать логи в текстовом формате, и нагрузка от rmngr.exe должна существенно снизиться.
Иногда rmngr.exe начинает сходить с ума из-за некорректной обработки спящих сеансов. Платформа может порождать их в огромном количестве, пытаясь поддерживать связь с клиентами. Посмотрим на параметры базы данных в консоли администрирования.
По умолчанию 1С может хранить спящие сеансы до 24 часов. Если в вашей сети много нестабильных соединений (VPN, мобильный интернет), количество таких сеансов растет лавинообразно. Рекомендуем уменьшить время жизни спящего сеанса до разумных пределов (например, 20–30 минут) и время завершения спящего сеанса.
Проанализируем ситуацию в консоли: если вы видите сотни сеансов без активности, это явный признак проблемы. Настройте автоматическое завершение таких сеансов в свойствах базы в консоли серверов 1С. Для автоматизации этого процесса можно использовать подсистему автозавершения неактивных сеансов 1С.
По умолчанию один процесс rmngr.exe обслуживает абсолютно все сервисы кластера. Мы можем «разгрузить» его, заставив систему запускать отдельный процесс под каждый тип сервиса. Рассмотрим, как это сделать:
После перезапуска вы увидите в диспетчере задач несколько процессов rmngr.exe. Это не только распределит нагрузку по ядрам процессора, но и позволит вам точно определить, какой именно сервис (например, сервис журналов регистрации или сервис полнотекстового поиска) потребляет ресурсы. Для комплексной проверки параметров кластера и рабочих процессов подойдёт обработка для чек-апа настроек сервера 1С.
Проанализируем еще одну возможную причину — сервис полнотекстового поиска (ППС). Если индексы ППС повреждены, rmngr.exe может бесконечно пытаться их проиндексировать. Попробуем выполнить следующие действия:
В пользовательском режиме (или через консоль) временно отключим полнотекстовый поиск. Если нагрузка упала — проблема в нем. В таком случае необходимо выполнить полную очистку и обновление индекса. Это можно сделать программно:
ПолнотекстовыйПоиск.ОчиститьИндекс();
ПолнотекстовыйПоиск.ОбновитьИндекс(Истина);
Также рекомендуется проверить папку index в каталоге базы данных внутри srvinfo. Если ее размер аномально велик, это может создавать нагрузку на дисковую подсистему и процессор при каждом изменении данных.
Процесс rmngr.exe крайне чувствителен к задержкам при чтении файлов в папке srvinfo. Если ваш антивирус проверяет каждый файл лога при записи, это создает очередь ожидания. Обязательно добавьте папку с данными сервера 1С в исключения антивируса.
Кроме того, на старых версиях Windows Server и платформы 1С 8.3.7 наблюдались проблемы с протоколом IPv6. Если сервер пытается разрешить имена через IPv6 и получает таймауты, это отражается на нагрузке процессора. Рекомендуем отключить IPv6 в свойствах сетевого адаптера или приоритезировать IPv4 через реестр Windows.
Как показывает опыт администраторов, переход на формат .lgf (Решение 1) в сочетании с разделением менеджеров сервисов (Решение 3) решает проблему в 90% случаев. После проделанных действий первый запуск баз может быть чуть дольше обычного, так как система перестраивает механизмы работы с логами, однако общая отзывчивость сервера и стабильность работы тонких клиентов значительно повысятся. Нагрузка на rmngr.exe должна стабилизироваться в районе 1–5%, а скачки процессора станут кратковременными и обоснованными реальными задачами пользователей.