Многие администраторы систем 1С после перехода на версии платформы 8.3.17 и 8.3.18 столкнулись с неприятной ситуацией: процесс rmngr начинает потреблять аномально много ресурсов центрального процессора. Нагрузка может достигать 70–99% на одно ядро или распределяться по всем доступным мощностям, при этом в консоли кластера может наблюдаться минимальное количество активных пользователей. Рассмотрим подробнее, почему это происходит и какими способами можно вернуть серверу стабильность.
Проанализируем архитектуру работы сервисов. В современных версиях 1С за ведение логов отвечает служба EventLogService, работающая внутри менеджера кластера rmngr. Основная причина избыточного потребления ресурсов кроется в неоптимальных алгоритмах синхронизации потоков при записи и чтении данных из журнала регистрации, если он хранится в старом текстовом формате (файлы с расширением .lgp).
Проблема была официально зарегистрирована компанией 1С под номером 10225558. Суть ошибки заключается в том, что при интенсивной работе (особенно при большом количестве коротких фоновых заданий) менеджер журнала регистрации входит в цикл бесконечного ожидания или избыточной индексации текстовых файлов, что и приводит к «пожиранию» ресурсов CPU.
Самым эффективным и быстрым способом решения проблемы без немедленного обновления всей платформы является смена формата хранения журнала регистрации с текстового на бинарный (база данных SQLite). Разберем по шагам, как это сделать:
Если автоматическая конвертация не удается или база слишком велика, мы рекомендуем поступить следующим образом:
1. Остановить службу "1C:Enterprise 8.3 Server Agent".
2. Перейти в каталог размещения служебных файлов (обычно srvinfo/reg_1541/ID_базы/1Cv8Log).
3. Переместить или переименовать старые файлы .lgp (это ваш архив).
4. Запустить службу сервера.
5. В Конфигураторе установить формат SQLite — будет создан чистый файл .lgd.
Если перевод на SQLite по каким-то причинам невозможен (например, используются внешние системы анализа логов, работающие только с .lgp), необходимо обновить технологическую платформу. Разработчики 1С выпустили исправления в следующих ветках:
Проанализируем ситуацию, когда даже после смены формата нагрузка остается ощутимой. Часто это связано с избыточной активностью регламентных заданий. Каждое выполнение задания порождает минимум две записи в журнал: «Старт» и «Завершение». Если у вас 100 баз и в каждой задание запускается раз в 30 секунд, EventLogService будет работать непрерывно.
Посмотрим на программный способ управления уровнем детализации журнала, чтобы снизить нагрузку:
// Пример кода для установки минимального уровня регистрации
Настройки = Новый НастройкиЖурналаРегистрации;
Настройки.Использование = Истина;
// Регистрируем только ошибки и предупреждения
Настройки.УровеньРегистрации = УровеньЖурналаРегистрации.Предупреждение;
УстановитьИспользованиеЖурналаРегистрации(Настройки);
Установка уровня УровеньЖурналаРегистрации.Предупреждение вместо Примечание позволяет отсечь тысячи записей об успешных сеансах и фоновых заданиях, что значительно разгружает rmngr.
Выясним еще одну важную деталь: новый формат журнала .lgd использует движок SQLite, который активно создает временные файлы в папке 1Cv8Log. Антивирусы часто пытаются сканировать эти файлы при каждом обращении сервера 1С к логу. Это создает лавинообразный эффект нагрузки.
Обязательно добавьте в исключения антивируса:
srvinfo (или путь, где лежат данные кластера)..lgp, .lgd, .lgf.rphost.exe, rmngr.exe, ragent.exe.Рассмотрим важные моменты, с которыми придется столкнуться после перехода на новый формат. Хотя он решает проблему с процессором, он требует внимания:
srvinfo.VACUUM внутри SQLite..lgd более чувствительны к некорректному завершению работы сервера (например, при отключении питания), чем текстовые логи. Регулярно делайте бэкап папки с логами, если история действий пользователей критически важна.Таким образом, для устранения высокой нагрузки со стороны EventLogService мы рекомендуем в первую очередь перевести критичные базы на формат SQLite и запланировать обновление платформы до актуальных релизов (не ниже 8.3.18.1483). Это обеспечит стабильную работу сервера и высвободит ресурсы процессора для полезных вычислений.