Как найти причину утечки памяти в процессе rphost и устранить резкое исчерпание ОЗУ на сервере 1С?

В процессе эксплуатации высоконагруженных информационных баз 1С:Предприятия администраторы нередко сталкиваются с ситуацией, когда один из рабочих процессов rphost внезапно за считанные секунды забирает всю доступную оперативную память сервера. При этом процесс не освобождает ресурсы вплоть до принудительного перезапуска по таймауту. Разберем по шагам, почему возникает такое поведение и как точно локализовать проблемный вызов с помощью средств платформы и технологического журнала.

1. Настройка технологического журнала для отлова ресурсоемких контекстов

Основным инструментом для поиска источника лавинообразного потребления памяти является технологический журнал (ТЖ). Проанализируем, какие именно события и свойства необходимо отслеживать:

1. Сбор событий потребления памяти: настроим сбор событий MEM и MEM2, фиксирующих выделение памяти сеансами и вызовами. В конфигурационном файле logcfg.xml зададим фильтрацию по объему памяти, чтобы логировать только аномальные всплески.
2. Анализ контекста вызова: включим сбор свойства Context для событий CALL, SCALL и DBMSSQL. Это позволит связать всплеск потребления памяти с конкретной строкой программного модуля или запросом.
3. Мониторинг длительных серверных вызовов: зафиксируем вызовы с высоким значением переданных и полученных данных (параметры Memory, MemoryPeak, InBytes, OutBytes).

Рассмотрим пример типового фрагмента файла конфигурации технологического журнала logcfg.xml для отслеживания потребления ресурсов:

<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\LOGS\1C_Memory" history="24">
        <event>
            <eq property="name" value="MEM"/>
        </event>
        <event>
            <eq property="name" value="MEM2"/>
        </event>
        <event>
            <eq property="name" value="CALL"/>
            <ge property="MemoryPeak" value="104857600"/>
        </event>
        <property name="all"/>
    </log>
</config>

После активации ТЖ проанализируем логи в момент инцидента. Наша цель — найти сеанс (process, AppID, SessionID) и метод встроенного языка, который предшествовал резкому скачку MemoryPeak.

2. Анализ прикладного кода и типичных сценариев утечки памяти

Выясним наиболее частые прикладные причины, приводящие к быстрому заполнению ОЗУ процессом rphost:

1. Неограниченная выгрузка таблиц в память: использование конструкций Запрос.Выполнить().Выгрузить() для получения сотен тысяч или миллионов записей вместо поэтапного обхода выборки через Выборка = Запрос.Выполнить().Выбрать(). Вся выгруженная таблица значений полностью материализуется в памяти рабочего процесса.
2. Тяжелые отчеты системы компоновки данных (СКД): формирование отчетов за большой период без строгих отборов с детализацией до документов-регистраторов. При расчете итогов и иерархических группировок компоновщик макета строит полное дерево данных в оперативной памяти.
3. Зацикливание в рекурсивных алгоритмах: распространенная проблема в производственных конфигурациях (например, разузлование спецификаций или состава изделия). Если в иерархии номенклатуры возникает перекрестная ссылка самой на себя, рекурсивная функция порождает бесконечный цикл создания объектов до исчерпания всей памяти.
4. Непотоковая обработка больших файлов: чтение документов XML или JSON через объектные модели (DOMДокумент, фабрика XDTO) целиком, вместо последовательного потокового чтения через объект ЧтениеXML или ЧтениеJSON.
5. Неосвобождаемые внешние COM-объекты: вызов внешних компонент или MS Office на стороне сервера без явного закрытия и уничтожения ссылок. Память в таком случае может не возвращаться сборщику мусора до завершения процесса.
6. Включенная серверная отладка: работа рабочего сервера с активным ключом -debug в производственной среде может приводить к накоплению служебных структур и утечкам памяти.

3. Корректировка параметров кластера серверов 1С

Чтобы исключить падение всего сервера из-за одного некорректного пользовательского действия, оптимизируем параметры кластера через консоль администрирования:

1. Интервал превышения допустимого объема памяти: по умолчанию параметр составляет 300 секунд. Рекомендуется уменьшить его до 30–60 секунд. Это гарантирует, что процесс, превысивший лимит, будет оперативно перезапущен без длительной заморозки ресурсов всего сервера.
2. Максимальный объем памяти рабочих процессов: зададим предельный объем (в байтах), по достижении которого процесс блокирует назначение новых соединений и отправляется на перезапуск.
3. Объем памяти рабочих процессов, до которого сервер считается производительным: скорректируем порог, чтобы кластер заранее плавно перенаправлял новые сеансы на менее нагруженные рабочие процессы.
4. Требования назначения функциональности (ТНФ): изолируем выполнение фоновых заданий, отчетов и интеграционных сервисов на выделенные рабочие процессы или отдельные узлы кластера.

4. Системные ограничения на уровне операционной системы

Для дополнительной защиты операционной системы от полного зависания применим ограничения ресурсов ОС Windows:

1. Использование Windows Job Objects: ограничим суммарный объем виртуальной и физической памяти для пула процессов rphost.exe через механизмы управления квотами ОС, чтобы оставить гарантированный резерв для системных служб.
2. Счетчики системного монитора: настроим отслеживание счетчиков Process \ Private Bytes и Process \ Working Set для процессов 1С, сопоставляя их с временными метками технологического журнала.

Таким образом, сочетание мониторинга через технологический журнал, ужесточения интервалов перезапуска процессов в кластере и оптимизации тяжелых запросов позволяет полностью локализовать и устранить причины неконтролируемого расхода памяти.