← На главную

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

Архитектура управления процессами в 1С 8.3

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

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

Причины автоматического создания второго рабочего процесса

Выясним основные причины, приводящие к появлению дополнительных процессов rphost:

1. Фоновые задания и служебные соединения. Каждое регламентное или фоновое задание, сеанс веб- или HTTP-сервиса, а также соединение отладчика учитывается менеджером кластера как отдельное соединение. При пиковых нагрузках общее число соединений может кратковременно превысить заданный порог балансировки.
2. Механизмы контроля памяти и перезапуска. Если в свойствах кластера или рабочего сервера заданы параметры контроля использования оперативной памяти (Интервал перезапуска, Допустимый объем памяти, Интервал превышения допустимого объема памяти), менеджер кластера запускает новый процесс для плавной смены, а старый помечает как устаревший. До момента выхода всех сеансов со старого процесса в системе одновременно работают оба rphost.
3. Использование 32-разрядного сервера 1С. В 32-битной редакции сервера адресное пространство одного процесса ограничено (2–3 ГБ). Платформа автоматически запускает новые процессы при приближении к порогу памяти, игнорируя настройки соединений.
4. NUMA-архитектура многопроцессорных серверов. На физических серверах с несколькими сокетами платформа может оптимизировать вызовы и распределять процессы по отдельным NUMA-узлам.

Пошаговая настройка для минимизации количества процессов

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

1. Увеличиваем лимит соединений на процесс. Перейдем в свойства рабочего сервера и установим параметр Количество соединений на процесс со значительным запасом (например, 256 или 512). Это предотвратит создание новых процессов из-за всплесков регламентных задач.
2. Проверяем уровень отказоустойчивости. В свойствах кластера параметр Уровень отказоустойчивости должен быть равен 0, если сервер работает в одиночном режиме без резервирования.
3. Отключаем автоматический перезапуск процессов. В свойствах кластера и рабочего сервера убедимся, что параметр Интервал перезапуска установлен в значение 0, если ротация процессов не требуется.
4. Корректируем контроль памяти. Параметры Допустимый объем памяти и Интервал превышения допустимого объема памяти устанавливаем в 0 (либо задаем гарантированно недостижимые значения), чтобы платформа не инициировала преждевременный перезапуск rphost.
5. Снимаем флаг завершения проблемных процессов при отладке. Опцию Завершать проблемные процессы не рекомендуется включать без явной необходимости, так как это может приводить к принудительному завершению и последующему перезапуску рабочих процессов.
6. Очищаем сеансовые данные. При необходимости остановим службу сервера 1С:Предприятие (ragent), удалим временные файлы и сеансовые данные из каталога srvinfo (файлы журналов и кэш сеансов) и запустим службу заново.

Особенности завершения устаревших процессов

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

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