Рано или поздно любой системный администратор или DevOps-специалист, обслуживающий крупную инфраструктуру 1С, сталкивается с ситуацией, когда рабочие процессы rphost начинают лавинообразно поглощать оперативную память сервера. Ситуация часто обостряется при переезде на новое оборудование или при обновлении платформы: сервер снабжают внушительным объемом ОЗУ (96 Гб, 128 Гб и более), но система «съедает» всё доступное пространство за считанные часы. Это приводит к уходу сервера в глубокий своп, диким задержкам в работе пользователей и зависанию всей системы.
В этой статье мы подробно проанализируем причины этой проблемы, разберем скрытые механизмы утечек памяти в платформе 1С:Предприятие 8.3 и выработаем комплексный пошаговый план стабилизации работы вашего кластера.
Одной из наиболее частых причин лавинообразного роста потребления памяти процессами rphost и rmngr являются зарегистрированные ошибки самой платформы 1С. Особенно ярко это проявляется на релизах ветки 8.3.16 (например, 8.3.16.1063) и некоторых смежных версиях (8.3.13), где некорректно работает механизм полнотекстового поиска (ППД).
Проблема заключается в том, что при индексации или обновлении индекса полнотекстового поиска рабочие процессы зацикливаются, вызывая постоянную паразитную нагрузку на процессоры (до 30–60% даже при отсутствии активных пользователей) и пилообразный жор памяти со сбросом в файл подкачки. Это сопровождается серьезными замираниями интерфейса у пользователей.
Для устранения этой проблемы выполним следующие шаги:
При настройке интервалов автоматического перезапуска рабочих процессов многие администраторы совершают стандартную ошибку, оставляя параметры кластера по умолчанию. Рассмотрим правильную схему настройки параметров перезапуска в консоли администрирования кластера:
Основная проблема кроется в параметре «Выключенные процессы останавливать через». По умолчанию он равен 0.
Когда наступает время перезапуска процесса по интервалу (например, каждые 43200 секунд / 12 часов), старый процесс rphost помечается системой как «выключенный». Все новые сессии пользователей начинают перенаправляться на вновь созданный рабочий процесс. Однако старый процесс, накопивший в себе гигабайты «утёкшей» оперативной памяти, будет оставаться запущенным в операционной системе до тех пор, пока из него не выйдет самый последний пользователь или не завершится зависшее фоновое задание.
Если в системе есть «зависшие» сеансы или бесконечные фоновые задания (например, частые регламентные обмены), старый процесс с огромным потреблением ОЗУ может висеть сутками. В результате на сервере одновременно функционируют и старые «забитые» процессы, и новые рабочие процессы, что удваивает или удваивает потребление памяти.
Решение: Установите параметр «Выключенные процессы останавливать через» в значение от 60 до 180 секунд. По истечении этого времени сервер 1С принудительно завершит старый процесс rphost, освободив занятую им оперативную память в ОС, а все недозакрытые сессии будут автоматически переподключены к новым процессам.
Если в вашем кластере развернуто большое количество информационных баз (100 и более), подход к распределению процессов играет ключевую роль.
Существует рекомендация создавать отдельный рабочий процесс rphost на каждую информационную базу. Это действительно помогает изолировать проблемные базы и локализовать утечки. Однако этот подход имеет обратную сторону — высокий оверхед (накладные расходы памяти).
Каждый процесс rphost даже в состоянии «холостого хода» (без активных пользователей) потребляет от 200 до 400 Мб оперативной памяти только на поддержание собственного окружения и кэшей метаданных. Если запустить 100 баз в режиме «один процесс на базу», сервер мгновенно потеряет от 20 до 40 Гб ОЗУ исключительно на поддержание процессов, не выполнив ни одной полезной операции.
Для оптимизации распределения памяти применим метод группировки:
rphost на сервер), что существенно сократит накладные расходы памяти.Когда общие настройки выполнены, но память продолжает утекать, необходимо выяснить конкретную причину: какой именно код или фоновое задание вызывает утечку. Попытка включить сбор ТЖ «для всего подряд» гарантированно обрушит производительность дисковой подсистемы сервера из-за сотен мелких регламентных заданий (таких как загрузка курсов валют, обновление СПАРК Рисков, классификаторов банков и т.д.).
Для безопасного и точечного анализа утечек памяти мы должны настроить фильтрацию событий в конфигурационном файле logcfg.xml.
Рассмотрим пример настройки ТЖ для фиксации только событий утечек памяти (LEAKS):
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\v8\logs\leaks" history="24">
<event>
<eq property="Name" value="LEAKS"/>
</event>
<property name="all"/>
</log>
</config>
Событие LEAKS фиксирует факты неосвобождения памяти при уничтожении программных объектов 1С (например, при образовании циклических ссылок в кодовой базе кастомных доработок). Данный лог будет весить совсем немного, но точно укажет на проблемные участки кода.
Дополнительно мы можем отслеживать тяжелые серверные вызовы (событие CALL), потребляющие аномально много ОЗУ. Чтобы не перегружать диск, установим фильтр по объему пикового потребления памяти (например, фиксировать только вызовы, превышающие 1 Гб памяти):
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\v8\logs\heavy_calls" history="12">
<event>
<eq property="Name" value="CALL"/>
<gt property="MemoryPeak" value="1073741824"/>
</event>
<property name="all"/>
</log>
</config>
Этот лог позволит мгновенно выявить конкретных пользователей, отчеты или фоновые задания, выполнение которых приводит к резким скачкам потребления ОЗУ на сервере.
Важно помнить об архитектурных ограничениях, накладываемых типом используемых лицензий 1С:
rphost, задать «Временно допустимый объем памяти» и интервал превышения лимита. При достижении этих порогов сервер самостоятельно и мягко перезапустит проблемный процесс.rphost могут беспрепятственно разрастаться до тех пор, пока операционная система принудительно не завершит их по критическому недостатку памяти или не сработает аварийный перезапуск всего сервера.Решение для ПРОФ: Если вы используете ПРОФ-лицензии, автоматизируйте контроль памяти с помощью внешних скриптов (PowerShell или bash), которые раз в несколько минут опрашивают запущенные процессы rphost через утилиты администрирования rac / ras или WMI и принудительно завершают те процессы, объем памяти которых превысил критическую отметку (например, 4–6 Гб на один процесс).
Как показывает практика, виновниками утечек памяти далеко не всегда являются встроенные механизмы 1С или ошибки в кодовой базе конфигурации. Любые сторонние внешние компоненты (компоненты защиты СЛК, такие как Катран, утилиты распознавания файлов, компоненты генерации штрихкодов, модули криптографии и отправки отчетности) загружаются и выполняются непосредственно в адресном пространстве процесса rphost.
Если во внешней компоненте допущена ошибка работы с памятью (например, выделенная память под объекты C++ не освобождается после завершения вызова), то утекать будет память процесса rphost, и сама платформа 1С не сможет этот процесс проконтролировать или очистить.
Рекомендации по локализации: Если вы подозреваете влияние сторонних систем защиты или внешних компонент: