Приветствуем, коллеги! Часто системные администраторы сталкиваются с неприятной ситуацией: на сервере 1С процесс rmngr.exe (Главный менеджер кластера) начинает сильно грузить процессор. Причем высокая загрузка CPU может наблюдаться круглые сутки, даже ночью, когда в базах нет активных пользователей, а фоновые и регламентные задания сведены к минимуму. Рассмотрим подробнее, как выяснить причину такого поведения платформы 1С:Предприятие 8.3 и разберем по шагам эффективные методы решения этой проблемы.
Процесс rmngr.exe — это не просто монолитный «черный ящик». Внутри него работает множество различных сервисов кластера 1С: сервис лицензирования, сервис сеансовых данных, сервис блокировок, сервис полнотекстового поиска и другие. Чтобы не гадать, какой именно механизм вызывает перегрузку, проанализируем ситуацию с помощью встроенных инструментов администрирования.
Сделаем следующее:
Теперь в диспетчере задач операционной системы появится множество процессов rmngr.exe с разными идентификаторами (PID). Вычислив тот PID, который забирает на себя процессорное время, мы сможем зайти обратно в консоль (раздел «Менеджеры кластера») и точно посмотреть, какой именно сервис отвечает за этот процесс. Это сузит круг поиска.
Одной из самых частых причин постоянной нагрузки на процессор является формат журнала регистрации. Начиная с версии платформы 8.3, система по умолчанию использует новый формат логов на базе СУБД SQLite (файлы с расширением .lgd).
Именно процесс rmngr отвечает за постоянную запись событий в этот лог. Со временем, особенно если у вас 10 и более баз, файлы SQLite сильно разрастаются и фрагментируются. Постоянные обращения к таким базам вызывают колоссальную нагрузку на процессор и диски (IOPS) даже ночью, так как в лог пишутся системные фоновые события.
Как решить:
.lgf). На практике он работает быстрее и создает меньше нагрузки на менеджер кластера..lgd и очистку устаревших записей.Если используется 32-битная версия сервера 1С (x32), то проблема может заключаться в банальной нехватке памяти. Архитектура x32 имеет жесткий лимит на выделение оперативной памяти на один процесс — обычно это 2 ГБ (или до 3 ГБ при использовании специальных ключей ОС).
Когда у вас работает много баз (например, 10 баз, как в рассматриваемом случае), главный менеджер кластера быстро упирается в этот лимит. Что происходит дальше? Процесс начинает непрерывно вызывать сборщик мусора (Garbage Collector), пытаясь освободить хотя бы немного памяти, и активно сбрасывает данные в файл подкачки (swap). Этот процесс требует огромных ресурсов CPU, и внешне это выглядит как 100% загрузка процессора процессом rmngr.exe.
Как решить: В современных реалиях использование 32-битного сервера 1С для продуктивных баз крайне не рекомендуется. Запланируйте апгрейд лицензий и переход на 64-битную платформу сервера 1С.
Менеджер кластера контролирует все сеансы пользователей. По умолчанию платформа 1С сохраняет «спящие» сеансы (разорванные соединения) в течение 24 часов. В случае проблем с сетевой инфраструктурой или сбоев тонкого клиента могут каждую секунду плодиться новые зависшие сеансы. Их количество может быстро достичь тысяч.
Постоянная обработка и удержание в памяти этого огромного пула сеансовых данных заставляет rmngr работать на пределе возможностей.
Как решить:
Даже если вы отключили все пользовательские регламентные задания, встроенные механизмы полнотекстового поиска часто отрабатывают незаметно. Регламентные задания по слиянию и обновлению индекса ППД запускаются платформой автоматически.
При наличии большого количества баз одновременное обновление полнотекстового индекса может создавать постоянную, круглосуточную нагрузку на менеджер кластера, который обслуживает этот сервис. В таких условиях регулярный контроль состояния систем упрощает автоматическое архивирование и тестирование баз 1С с отправкой результатов по электронной почте.
Как решить: Если полнотекстовый поиск реально не нужен пользователям в работе, принудительно отключите его использование. Это делается в режиме Предприятия в разделе администрирования, где нужно снять галочку с использования полнотекстового поиска данных.
Дополнительно посмотрим на проблему со стороны системы управления базами данных (СУБД). Запустите консоль или профайлер на вашем SQL-сервере и проанализируйте в реальном времени, какие запросы выполняются во время пиковой нагрузки. Это поможет понять, не генерирует ли платформа 1С аномальное количество служебных запросов, которые косвенно заставляют менеджер кластера 1С «закипать» в ожидании ответа от СУБД.
Проанализировав эти 6 шагов, вы сможете с высокой долей вероятности найти и устранить причину высокой загрузки процессора процессом Главного менеджера кластера. Удачи в оптимизации ваших серверов 1С!