Почему размножаются рабочие процессы rphost на сервере 1С и как это исправить

← На главную

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

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

Основные причины размножения процессов rphost

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

Рассмотрим ключевые факторы, из-за которых старые процессы не могут завершиться и накапливаются в памяти:

Зависшие клиентские соединения и сетевые дескрипторы: если клиентский сеанс оборвался некорректно (например, при уходе клиентского ПК в спящий режим или обрыве Wi-Fi), операционная система сервера может долго удерживать сетевой сокет. Пока открыты TCP-дескрипторы или файловые блокировки, процесс rphost не может выгрузиться из памяти, а для новых подключений создаются свежие процессы.
Некорректная конфигурация параметров кластера: если в свойствах кластера или рабочего сервера не задано принудительное завершение сбойных процессов, выключенный процесс может часами ожидать штатного освобождения потоков, удерживая занятые ресурсы.
Задержки и переподписка ресурсов на гипервизорах (VMware, Hyper-V): высокая конкуренция за процессорные ядра (высокий показатель CPU Ready Time), включенные механизмы динамического энергосбережения или некорректное распределение NUMA-узлов приводят к микрозадержкам гостевой ОС. Менеджер кластера не получает вовремя контрольный сигнал (heartbeat) от rphost, считает процесс зависшим и спавнит новый.
Цикличный перезапуск по превышению памяти: при достижении лимита «Допустимый объем памяти» платформа инициирует перезапуск процесса. Если новые вызовы пользователей поступают непрерывно, а старый процесс не успевает освободить память, запускается лавинообразное размножение rphost.

Шаг 1. Настройка параметров кластера серверов 1С

Для предотвращения бесконтрольного накопления неактивных и зависших процессов настроим свойства кластера в консоли администрирования (утилита ras или оснастка MMC):

Откроем консоль администрирования серверов 1С:Предприятия.
Перейдем в свойства нужного кластера серверов.
Установим флаг Принудительно завершать проблемные процессы в значение Да (или выставим флажок). Это разрешает менеджеру кластера принудительно снимать процессы, переставшие отвечать на системные пинги.
Параметр Выключенные процессы останавливать через установим в значение 60 (секунд). Это ограничит время жизни неактивного процесса: если за 60 секунд оставшиеся транзакции не завершились штатно, процесс будет завершен принудительно на уровне ОС.
Проверим параметр Интервал перезапуска: для профилактики дефрагментации памяти рекомендуется задать значение 86400 (перезапуск раз в сутки).

Шаг 2. Анализ настроек распределения баз и соединений

Обратим внимание на параметры масштабирования процессов в свойствах рабочего сервера:

Количество ИБ на процесс: если установить значение 1, платформа будет выделять отдельный rphost под каждую информационную базу. Если на сервере развернуто несколько десятков баз, это автоматически создаст соответствующее количество процессов, увеличивая накладные расходы на межпроцессное взаимодействие. Для серверов с большим числом баз оптимально оставлять значение по умолчанию (0 — без ограничений).
Количество соединений на процесс: слишком низкое значение данного параметра при высокой активности пользователей заставит кластер создавать новые процессы для обработки очередных пачек подключений. Проанализируем нагрузку и зададим сбалансированное значение исходя из доступных ресурсов сервера (обычно от 128 до 256 соединений на процесс).

Шаг 3. Оптимизация сетевого стека и параметров виртуализации

Если сервер 1С развернут на базе виртуальной машины (например, VMware vSphere), выполним тонкую настройку окружения:

Резервирование ресурсов (Reservation): зафиксируем для виртуальной машины с сервером 1С 100% резервирование оперативной памяти (Memory Reservation) и исключим переподписку vCPU, чтобы избежать задержек гостевой ОС.
Схема электропитания: на хосте виртуализации и внутри гостевой ОС установим план высокой производительности (High Performance), отключив глубокие состояния энергосбережения процессора (C-states).
Таймауты TCP Keep-Alive в ОС: уменьшим интервалы проверки зависших сетевых соединений в реестре операционной системы (параметры KeepAliveTime и KeepAliveInterval), чтобы сервер быстрее сбрасывал "мертвые" сокеты пользователей, потерявших связь.

Шаг 4. Локализация проблемных операций через Технологический журнал

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

Создадим минимальный файл конфигурации logcfg.xml в каталоге настроек платформы для отслеживания аварийных завершений и исключений:


<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\LOGS\1C_EXCP" history="24">
        <event>
            <eq property="name" value="EXCP"/>
        </event>
        <event>
            <eq property="name" value="PROC"/>
        </event>
        <property name="all"/>
    </log>
</config>

События EXCP зафиксируют критические исключения, а события PROC покажут моменты запуска, остановки и принудительного уничтожения процессов rphost. Проанализировав логи, выясним, какой пользовательский сеанс, фоновое задание или внешняя компонента приводит к зависанию потока.