Как увеличить количество рабочих процессов rphost в 1С 8.3 и решить проблему утечки памяти

Разберем распространенную проблему администрирования кластера серверов 1С:Предприятие 8.3, когда рабочий процесс rphost.exe потребляет 3.5–3.7 Гб оперативной памяти, после чего информационная база перестает принимать новые подключения и становится недоступной для пользователей.

Выясним причину такого поведения, проанализируем отличия архитектуры платформы 8.3 от 8.2 и подробно рассмотрим все способы разделения процессов и ограничения потребления ресурсов.

Почему процесс rphost аварийно завершает работу при 3.5–3.7 Гб памяти

Проанализируем природу этого ограничения. Поведение характерно для 32-разрядного сервера 1С:Предприятия (x86), работающего под управлением 64-разрядной операционной системы. Теоретический адресный предел 32-битного процесса в 64-битной Windows составляет 4 Гб. Однако на практике из-за сильной фрагментации адресного пространства процесс не может выделить непрерывный блок памяти уже при достижении 3.5–3.7 Гб, что вызывает критические ошибки нехватки памяти (Out of Memory) и зависание базы данных.

Принципы выделения процессов rphost в платформе 1С 8.3

В отличие от платформы 1С 8.2, где администратор мог вручную добавить требуемое количество рабочих процессов через консоль кластера, в версии 8.3 реализовано автоматическое управление процессами. Создать процесс напрямую вручную нельзя — кластер серверов запускает их динамически на основе установленных правил и порогов нагрузки.

Рассмотрим алгоритм, по которому кластер определяет необходимость запуска нового процесса:

1. Для рабочего сервера проверяется текущий список процессов и количество обслуживаемых баз. Учитывается свойство Количество ИБ на процесс.
2. Проверяется загруженность процесса по подключениям согласно свойству Количество соединений на процесс (в более новых версиях — Количество сеансов на процесс).
3. Проверяется, не находится ли рабочий процесс в режиме подготовки к плановому или аварийному перезапуску.
4. Приоритет отдается тому процессу, который уже обслуживает подключения данной информационной базы.
5. Если ни один из существующих процессов не удовлетворяет заданным лимитам, кластер автоматически порождает новый экземпляр rphost.exe.

Способы увеличения количества рабочих процессов

Разберем практические шаги для принудительного разделения нагрузки на несколько процессов rphost.

Способ 1. Уменьшение лимитов в свойствах рабочего сервера

Откроем консоль администрирования кластера серверов 1С и перейдем в свойства рабочего сервера:

1. Установим параметр Количество ИБ на процесс равным 1. В этом случае каждая информационная база гарантированно будет обслуживаться собственным рабочим процессом, что исключит взаимное влияние баз друг на друга.
2. Уменьшим значение параметра Количество соединений на процесс (или сеансов). Например, если установить лимит в 10–15 соединений, то при превышении этого порога кластер будет вынужден запустить дополнительный процесс rphost для обслуживания новых пользователей той же базы.

Способ 2. Настройка требований назначения функциональности (ТНФ)

Используем встроенный механизм ТНФ для изоляции баз и сервисов:

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

Управление памятью и защита от зависаний кластера

Рассмотрим параметры защиты кластера серверов от переполнения памяти, задаваемые в свойствах самого кластера:

1. Допустимый объем памяти — задает верхний предел потребления оперативной памяти (в байтах) для одного рабочего процесса. При превышении этого значения кластер запускает резервный процесс, переводит старый процесс в режим доработки существующих сеансов и затем перезапускает его, освобождая ресурсы.
2. Интервал превышения допустимого объема памяти — время (в секундах), в течение которого процесс может превышать установленный порог перед принудительной ротацией.
3. Безопасный расход памяти за один вызов — прерывает единичный серверный запрос или тяжелый отчет, если он за один раз запрашивает объем памяти больше заданного лимита. Это спасает процесс от падения из-за неоптимального кода.
4. Период перезапуска рабочих процессов — регулярный интервал времени, через который процессы планово перезапускаются для устранения фрагментации памяти и сброса утечек.

Кардинальные решения проблемы

Разберем системные методы, позволяющие полностью избавиться от падений процессов из-за нехватки памяти:

1. Переход на 64-разрядный сервер 1С:Предприятие (x86-64). 64-битный процесс rphost не имеет 4-гигабайтного ограничения и может адресовать весь физический объем RAM, установленный на сервере.
2. Запуск второго экземпляра службы сервера 1С. Если переход на x64 невозможен, создадим вторую службу 1С на других сетевых портах (например, порты 1640, 1641, 1660:1691). Это позволит разнести проблемную базу в отдельный изолированный экземпляр сервера со своим адресным пространством.
3. Оптимизация программного кода. Проанализируем алгоритмы и серверные модули: заменим полную выгрузку больших массивов данных через метод Выгрузить() на порционную обработку выборки, проверим корректность завершения COM-объектов и внешних компонент.