Как решить проблему, когда процесс rphost за несколько минут съедает всю оперативную память на сервере 1С?

Каждый системный администратор и разработчик 1С рано или поздно сталкивается с ситуацией, когда сервер приложений начинает вести себя непредсказуемо. Одна из самых неприятных проблем — лавинообразный рост потребления оперативной памяти рабочим процессом rphost. За считанные минуты один процесс может «поглотить» 25–30 Гб (и более) выделенной памяти, парализуя работу пользователей и приводя к зависанию всей системы.

В этой статье мы подробно разберем, почему возникает такое поведение, проанализируем внутренние механизмы платформы на примере работы тяжелых регламентных заданий и найдем несколько вариантов кардинального решения этой проблемы.

Выясняем первопричину: что нагружает rphost?

Как показывает практика и реальные кейсы с форумов, в подавляющем большинстве случаев виновником резкого расхода памяти является фоновое или регламентное задание. В современных конфигурациях, таких как 1С:ERP Управление предприятием, Комплексная автоматизация или Управление торговлей, одним из самых ресурсоемких процессов является регламентное задание «Выполнение отложенных движений по расчетам с клиентами/поставщиками».

Давайте разберем по шагам, для чего предназначено это задание. В системах автоматизации торговой деятельности используется так называемая оффлайн-схема взаиморасчетов. При проведении первичных документов (например, реализаций или поступлений) программа не тратит процессорное время на мгновенное распределение авансов и расчет долгов по срокам в режиме реального времени. Вместо этого система фиксирует изменения, записывая специальные маркеры (ключи аналитики) в технические регистры сведений:

• РегистрСведений.ЗаданияКРаспределениюРасчетовСКлиентами
• РегистрСведений.ЗаданияКРаспределениюРасчетовСПоставщиками

Затем, согласно настроенному расписанию, запускается фоновое задание. Оно считывает накопившиеся записи из этих регистров, производит сложные математические расчеты распределения взаиморасчетов по ФИФО и записывает финальные данные в регистры накопления (например, в РегистрНакопления.РасчетыСКлиентамиПоСрокам).

Почему происходит утечка памяти и зависание процесса?

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

1. Эффект «снежного кома» (переполнение очереди). Если регламентное задание по какой-то причине долгое время не выполнялось (например, было отключено или завершалось с ошибкой), в регистрах заданий к распределению накапливаются сотни тысяч или миллионы записей. При очередном старте алгоритм пытается обработать весь этот колоссальный объем за один транзакционный цикл. В результате вся таблица данных загружается в оперативную память процесса rphost.
2. Сложные пакетные запросы и квадратичная зависимость. Механизм распределения взаиморасчетов использует тяжелые пакетные запросы с временными таблицами. При превышении определенного объема обрабатываемых данных нагрузка на СУБД и память сервера приложений растет не линейно, а квадратично. Сервер СУБД тратит много времени на построение плана запроса, а процесс rphost ожидает выборку, накапливая кэш объектов в оперативной памяти.
3. Наличие некорректных (битых) данных. Если в информационную базу были загружены некорректные документы или произошел сбой при обмене данными, в регистры заданий могут попасть записи с пустыми измерениями (например, пустая организация, пустой контрагент или битая ссылка на документ расчетов). Алгоритм распределения, натыкаясь на такие записи, может уйти в бесконечный цикл, пытаясь перенести нераспределенный остаток на следующий период, что мгновенно забивает память сервера.
4. Конфликт с датой запрета изменения данных. Если фоновое задание пытается распределить расчеты за период, который уже закрыт установленной в системе датой запрета редактирования, транзакция проведения документов откатывается обратно. Однако само фоновое задание не завершается, а циклически пытается повторить операцию снова и снова, порождая утечку памяти в рабочем процессе.

Варианты решения проблемы

Простое решение в виде переноса времени запуска регламентного задания на глубокую ночь (как часто делают начинающие специалисты) лишь временно маскирует проблему. Ночью сервер все равно будет испытывать колоссальные перегрузки, что может сорвать выполнение других важных процедур (например, резервного копирования). Рассмотрим более надежные и системные методы исправления ситуации.

Способ 1. Переход на современную онлайн-архитектуру взаиморасчетов

Самым правильным и стратегическим решением для конфигураций на управляемых формах является отказ от устаревшей оффлайн-смы расчетов. Начиная с версий ERP 2.4.6 / КА 2.4.6 / УТ 11.4.6 разработчики фирмы 1С добавили оптимизированный режим — «Онлайн-взаиморасчеты».

Проанализируем преимущества этого режима:

• Все расчеты распределения долгов по срокам происходят мгновенно в момент проведения документов по оптимизированной оперативной очереди.
• Полностью отпадает необходимость функционирования тяжелого фонового задания отложенных движений.
• Исключаются ситуации с накоплением «хвостов» нераспределенных данных за прошлые периоды.

Чтобы включить этот режим, перейдем в раздел: НСИ и администрирование -> Казначейство и взаиморасчеты -> Взаиморасчеты и активируем соответствующую опцию перехода на онлайн-режим. Обратите внимание, что при включении режима система запустит однократную процедуру пересчета прошлых периодов, которую лучше выполнять в технологическое окно.

Способ 2. Программная очистка очередей распределения

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

Для этого мы можем написать простую внешнюю обработку, которая очистит или выборочно удалит «проблемные» записи из регистров сведений. Посмотрим на пример кода для полной очистки регистра заданий:

// Очистка очереди распределения расчетов с клиентами
НаборЗаписей = РегистрыСведений.ЗаданияКРаспределениюРасчетовСКлиентами.СоздатьНаборЗаписей();
// Записываем пустой набор, тем самым полностью очищая регистр
НаборЗаписей.Записать(Истина);

// Очистка очереди распределения расчетов с поставщиками
НаборПоставщики = РегистрыСведений.ЗаданияКРаспределениюРасчетовСПоставщиками.СоздатьНаборЗаписей();
НаборПоставщики.Записать(Истина);

Если полная очистка нежелательна, мы можем проанализировать записи регистра программно, найти записи с незаполненными ключевыми аналитиками или некорректными датами (например, даты из глубокого прошлого или далекого будущего) и удалить только их. После очистки регистров нагрузка на rphost мгновенно снизится, так как фоновому заданию больше нечего будет обрабатывать.

Способ 3. Настройка жестких лимитов потребления памяти в кластере 1С

Чтобы единичный сбой в коде или тяжелый отчет пользователя не приводили к падению всего сервера приложений, мы обязательно должны настроить параметры контроля памяти рабочих процессов. Это делается через консоль администрирования кластера серверов 1С:Предприятие.

Выполним настройку по шагам:

1. Откроем консоль администрирования кластера 1С.
2. Перейдем в свойства нашего рабочего сервера (в ветке Рабочие серверы).
3. Найдем параметр Допустимый объем памяти (указывается в байтах или килобайтах в зависимости от версии платформы). Зададим здесь лимит (например, 80% от общего объема RAM сервера).
4. Настроим параметр Интервал превышения допустимого объема памяти (например, 20–30 секунд).
5. Зададим параметр Выключать процессы с расходом памяти более. Это критическое значение, при превышении которого процесс будет принудительно завершен кластером.

Как это работает на практике? Если процесс rphost под нагрузкой превысит установленный лимит памяти и продержится в таком состоянии дольше заданного интервала времени, кластер серверов автоматически пометит этот процесс как «выключаемый». Для обслуживания новых подключений пользователей будет запущен новый, «чистый» процесс rphost, а старый, перегруженный процесс будет мягко остановлен, как только завершатся текущие активные вызовы.

Важное примечание: Начиная с версии платформы 8.3.20, базовые лимиты контроля и ограничения памяти рабочих процессов стали доступны не только в КОРП, но и в ПРОФ-лицензиях, что существенно упрощает администрирование средних и малых систем.

Способ 4. Изоляция фоновых заданий с помощью требований назначения функциональности

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

Для этого в консоли кластера создаются правила, согласно которым:

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

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

Резюме и рекомендации

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

• Всегда ведите мониторинг размера процессов rphost и оперативно реагируйте на аномальные скачки потребления RAM.
• Если вы используете ERP или Комплексную автоматизацию, запланируйте и осуществите переход на режим Онлайн-взаиморасчетов. Это избавит базу от тяжелых фоновых процедур распределения по ФИФО.
• Никогда не оставляйте параметры контроля памяти рабочего сервера в значениях по умолчанию. Обязательно настраивайте лимиты расхода памяти в консоли кластера 1С.
• Регулярно проводите аудит и профилактику базы на наличие некорректных или «битых» данных в технических регистрах сведений очереди распределения.