Рабочие процессы 1С в кластере: как распределяется нагрузка и почему rphost грузит сервер

К обеду база встаёт. Полтораста человек в «Бухгалтерии», проведение документа висит по сорок секунд, в диспетчере задач один rphost.exe держит 20 гигабайт и не отпускает. Первое, что приходит в голову, - поставить перед сервером балансировщик и раскидать людей по машинам.

Балансировщика в привычном смысле у 1С нет. Ни nginx, ни HAProxy между пользователем и кластером не встают: клиент подключается к агенту сервера, а дальше кластер сам решает, какому рабочему процессу отдать это соединение. Ручки, которыми это решение можно изменить, лежат в консоли администрирования кластера - и часть из них заблокирована лицензией уровня ПРОФ.

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

Про балансировщики как класс - Round Robin, L4 и L7, аппаратные и программные - у нас есть отдельный разбор: балансировка нагрузки между серверами. Здесь речь только про внутреннюю механику 1С.

Кто в кластере раздаёт нагрузку

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

ragent - агент сервера. Служба «Агент сервера 1С:Предприятия», стартует вместе с машиной. Отвечает за то, что этот компьютер вообще состоит в кластере, и ведёт список кластеров, которые на нём живут. Сам пользовательские запросы не обрабатывает.

rmngr - менеджер кластера. Управляет работой кластера: ведёт сеансы, лицензии, журнал регистрации, полнотекстовый поиск и прочие служебные сервисы. Главный менеджер хранит реестр кластера - его конфигурацию и текущее состояние. Компьютер, где работает главный менеджер, и называется центральным сервером.

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

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

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

Почему rphost грузит процессор и съедает память

Рабочий процесс редко обслуживает что-то одно. По умолчанию один rphost берёт на себя до восьми информационных баз и до 128 соединений. То есть тестовая копия, архивная база пятилетней давности и рабочая «Бухгалтерия» вполне могут жить в одном процессе и делить его память.

Дальше одно накладывается на другое.

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

Фоновые задания идут в общем потоке с людьми. Ночной обмен, пересчёт итогов, регламентное задание на закрытие месяца - всё это исполняется теми же рабочими процессами. Если задание запустилось в рабочее время, пользователи почувствуют его первыми.

Один неудачный запрос способен утянуть за собой процесс: соединение забирает память под выборку, процесс упирается в предел, и падают все сеансы, которые он обслуживал.

Смотреть, что происходит, надо в консоли администрирования кластера: раздел «Соединения» с колонками захваченных данных и времени вызова, раздел «Сеансы» - там видно, кто держит память и чей вызов идёт дольше остальных. Технологический журнал даст ту же картину подробнее, но начинать проще с консоли.

Параметры, которые меняют раскладку

Все настройки лежат в консоли администрирования: свойства кластера и свойства рабочего сервера. Ниже - те, что действительно влияют на распределение.