При администрировании серверов 1С:Предприятие системные администраторы нередко сталкиваются с ситуацией, когда процесс менеджера кластера rmngr.exe начинает лавинообразно расходовать оперативную память, занимая десятки гигабайт. При включении режима запуска отдельного процесса менеджера под каждый сервис кластера выясняется, что основным потребителем ресурсов выступает сервис заданий — jobService. При этом рабочие процессы rphost.exe могут продолжать работать в рамках допустимых лимитов потребления памяти. Разберем по шагам, почему возникает такое поведение платформы, как локализовать утечку и какие меры предпринять для стабилизации работы кластера.
Сервис заданий (jobService) выполняет роль брокера между исполняемым фоновым заданием внутри рабочего процесса rphost.exe и клиентским приложением. Рассмотрим подробнее основные архитектурные механизмы, приводящие к чрезмерному потреблению памяти:
СообщитьПользователю). Если длительное фоновое задание (например, массовое удаление помеченных объектов, проведение или импорт данных) в цикле формирует тысячи служебных оповещений с помощью вызова СообщитьПользователю(), все эти данные передаются и оседают в оперативной памяти jobService в виде очереди. Если пользователь запустил операцию и закрыл клиентское сеансовое окно, вычитывать этот буфер становится некому. В результате очередь сообщений непрерывно растет внутри адресного пространства процесса rmngr.exe, удерживающего сервис заданий.Важное ограничение платформы: штатные параметры кластера («Предельный объем оперативной памяти процессов», «Интервал превышения допустимого объема памяти») контролируют исключительно рабочие процессы rphost.exe. Механизмов автоматического контроля лимитов памяти и перезапуска для rmngr.exe на уровне кластера не предусмотрено, поэтому неконтролируемый рост менеджера может привести к отказу всего сервера.
Чтобы точно определить, какие фоновые задания приводят к разрастанию памяти, настроим сбор технологического журнала. Создадим или скорректируем файл logcfg.xml на сервере 1С. В конфигурацию технологического журнала необходимо включить аудит расхода памяти и события фоновых заданий для процесса менеджера кластера:
MEM — отслеживание динамики выделения оперативной памяти процессами кластера.LEAKS — сбор информации о потенциальных утечках памяти.JOB и EXCP — мониторинг жизненного цикла фоновых заданий, их параметров, фоновых модулей и возникающих исключений.Посмотрим на пример структуры файла logcfg.xml:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\LOGS\1C\RM_MEM" history="24">
<event>
<eq property="name" value="MEM"/>
</event>
<event>
<eq property="name" value="LEAKS"/>
</event>
<event>
<eq property="name" value="JOB"/>
</event>
<event>
<eq property="name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</config>
Анализ полученных логов позволит связать рост счетчиков памяти конкретного процесса rmngr.exe с выполнением определенных фоновых процедур.
Проанализируем прикладной код длительных фоновых обработок (в частности, алгоритмы удаления помеченных объектов или пакетного обновления данных). Основные правила оптимизации:
СообщитьПользователю(). В циклических операциях нельзя отправлять сообщения на каждой итерации. Если протоколирование необходимо, следует использовать запись в журнал регистрации пакетами или накапливать данные во временном текстовом файле на сервере:
// Неправильно: засоряет очередь jobService
Для Каждого СтрокаТЧ Из ТаблицаОбъектов Цикл
// обработка объекта
СообщитьПользователю("Обработан объект: " + СтрокаТЧ.Ссылка);
КонецЦикла;
// Правильно: порционная запись или журналирование
Если СчетчикОбработанных % 1000 = 0 Тогда
ЗаписьЖурналаРегистрации("МассоваяОбработка", УровеньЖурналаРегистрации.Информация, , , "Обработано объектов: " + СчетчикОбработанных);
КонецЕсли;
ФоновыеЗадания.Отменить(), если выполнение задания без контроля оператора недопустимо.Для минимизации влияния тяжелых заданий на работу пользователей кластера применим административные настройки:
jobService в отдельный процесс rmngr.exe. В случае критического переполнения памяти падение или принудительный перезапуск этого процесса не приведет к разрыву пользовательских сеансов и сервиса блокировок.BackgroundJob.CommonModule и BackgroundJob.ScheduledJob), назначив для них отдельный рабочий сервер или выделенный рабочий процесс кластера.rmngr.exe нет, настроим внешний скрипт мониторинга (например, PowerShell или агент системы мониторинга), отслеживающий счетчик Working Set процессов rmngr.exe, чтобы получать оповещения о нештатном потреблении оперативной памяти до наступления аварийной ситуации.