Серверная 1С изнутри: агент, менеджер, рабочие процессы и СУБД

Сервер 1С Предприятия состоит из трёх уровней: агент сервера (ragent), менеджер кластера (rmngr) и рабочие процессы (rphost). Клиент подключается к агенту, менеджер решает, какой рабочий процесс его обслужит, а сам процесс выполняет код и ходит в СУБД. Всё остальное, от ras до настроек перезапуска, надстройки над этой цепочкой.

Если знать, кто за что отвечает, диагностика упрощается. Тормозит один сеанс или все сразу? Падает процесс или не отвечает менеджер? Ответ на такие вопросы лежит в устройстве кластера.

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

Из чего состоит кластер серверов 1С

Кластер серверов 1С — это логическая группа процессов, которая обслуживает набор информационных баз. Один кластер может работать на одном физическом сервере или на нескольких.

Основные составляющие:

• 🧭 Агент сервера — процесс ragent. Он запускается как служба ОС, держит список кластеров на этой машине и принимает входящие подключения.
• 🗂 Менеджер кластера — процесс rmngr. Хранит состояние кластера и распределяет нагрузку.
• ⚙️ Рабочие процессы — rphost. Именно они исполняют серверный код, работают с запросами и держат пользовательские сеансы.
• 🖥 Сервер администрирования — ras. Отдельная служба для удалённого управления через утилиту rac или консоль.

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

Данные кластера (список баз, настройки, реестр) лежат в каталоге, который указан при запуске службы ключом -d. Обычно его называют srvinfo. Этот каталог входит в обязательный набор для резервной копии сервера, а потерять его значит потерять описание баз в кластере.

Что делает каждый процесс: ragent, rmngr, rphost, ras

Агент сервера ragent

Агент запускается первым и стартует всё остальное. Он создаёт менеджер кластера, следит за ним и перезапускает, если тот упал. Когда клиент стучится на порт 1540, отвечает именно агент.

Менеджер кластера rmngr

Менеджер — диспетчер. Он знает, сколько рабочих процессов запущено, какая у них загрузка и на каком процессе лежит нужный сеанс. Через него идёт:

• распределение новых подключений по рабочим процессам;
• учёт лицензий и сеансов;
• хранение блокировок, которые 1С ставит на уровне платформы;
• взаимодействие с консолью администрирования.

Главный менеджер в кластере один. В крупных схемах добавляют дополнительные менеджеры и раскладывают по ним сервисы.

Рабочий процесс rphost

Вся пользовательская работа происходит здесь. Процесс исполняет серверный код 1С, формирует запросы к СУБД, обрабатывает данные. Если rphost падает, пользователи на нём теряют сеансы, а остальные процессы продолжают работать. Поэтому в кластере держат несколько рабочих процессов, а не один.

Сервер администрирования ras

ras сам ничего не считает. Это прослойка, которая принимает команды управления и передаёт их агенту. Запуск простой:

ras cluster --port=1545 localhost:1540

Дальше к нему подключаются утилитой rac:

rac localhost:1545 cluster list

Команда покажет идентификатор кластера. Он нужен для всех следующих запросов, например для списка баз или сеансов.

Как проходит сеанс пользователя: от клиента до рабочего процесса

Понимание цепочки помогает искать причину «подвисаний». Работает так:

1. Клиент (толстый, тонкий или веб) обращается к серверу по адресу вида имя_сервера:1541 или через агент на 1540.
2. Агент отдаёт клиента менеджеру кластера.
3. Менеджер проверяет, что база доступна, а лицензия есть, и создаёт соединение.
4. Менеджер выбирает рабочий процесс по загрузке и назначает его клиенту.
5. Дальше клиент общается с этим rphost напрямую. Менеджер в каждом вызове уже не участвует.

Здесь два разных понятия, которые часто путают. Соединение — это канал между клиентом и рабочим процессом. Сеанс — это логическая сессия пользователя в базе, внутри которой выполняются вызовы. Один пользователь может держать несколько соединений, а фоновые задания создают собственные сеансы.

Что происходит при вызове сервера:

• клиент передаёт процессу команду, например проведение документа;
• rphost выполняет код, собирает запросы и отправляет их в СУБД;
• результат возвращается клиенту, а вызов фиксируется в счётчиках процесса.

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

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

Как сервер 1С работает с СУБД

Рабочий процесс не хранит данные сам. Все чтения и записи уходят в СУБД: PostgreSQL, Microsoft SQL Server, IBM Db2 или Oracle. Сервер 1С переводит запрос на языке 1С в SQL и отправляет его через драйвер.

Из этого следуют практические выводы:

• 🔌 Между rphost и СУБД идёт интенсивный сетевой обмен. Держите их в одной быстрой сети, лучше в одном дата-центре.
• 🧱 Сервер 1С и СУБД можно установить на одну машину или на разные. Для небольшой базы на 10–20 пользователей хватает одного сервера. Для нагруженных систем СУБД выносят отдельно, чтобы они не делили память.
• 🔒 Параллельность работы ограничена блокировками. Платформа ставит собственные управляемые блокировки в менеджере, а СУБД держит свои на уровне строк и страниц.

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

Что проверить на стороне СУБД в первую очередь:

Настройка кластера и параметров рабочих процессов

Настройки кластера открываются в консоли администрирования серверов 1С. Откройте нужный кластер, выберите его свойства и посмотрите параметры. Для рабочих серверов зайдите в раздел «Рабочие серверы» и откройте свойства нужного сервера.

Что стоит знать о ключевых параметрах:

• Интервал перезапуска рабочих процессов. Периодическое перезапускание защищает от утечек памяти. Значение в часах подбирают по нагрузке, у многих внедрений оно составляет несколько часов, в крупных системах чаще. Ноль отключает перезапуск.
• Допустимый объём памяти рабочих процессов. Когда процесс превышает порог, менеджер помечает его на завершение и создаёт новый.
• Интервал превышения допустимого объёма памяти. Сколько времени процессу позволено работать выше порога, прежде чем его завершат.
• Максимальное число соединений и информационных баз на процесс. Определяют, насколько плотно сеансы упаковываются на один rphost.
• Безопасное потребление памяти за один вызов. Защита от вызова, который съедает всю память разом.

Пример расчёта. На сервере 64 ГБ оперативной памяти, из них под ОС и СУБД на этом же сервере оставляют 24 ГБ. На рабочие процессы остаётся 40 ГБ. Если запланировать четыре рабочих процесса, на каждый приходится примерно 10 ГБ. Допустимый объём памяти ставят чуть ниже, чтобы запас был при пике.

Порядок аккуратной настройки:

1. Снимите текущие значения и запишите их.
2. Измените один параметр.
3. Понаблюдайте нагрузку хотя бы сутки.
4. Только после этого меняйте следующий.

Не правьте несколько параметров одновременно в рабочем кластере. Иначе непонятно, что дало эффект, а что ухудшило ситуацию.

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

rac localhost:1545 process list --cluster=<идентификатор_кластера>

Подставьте свой идентификатор, который вернула команда cluster list. По выводу видно, сколько памяти занимает каждый процесс и сколько у него соединений.

Масштабирование: несколько серверов и рабочих процессов

Когда один сервер не справляется, есть два пути: добавить ресурсов или добавить серверов в кластер.

Что выбирать:

• 📈 Вертикально. Больше памяти, быстрее диски, больше ядер. Просто, но у платформы и железа есть потолок.
• 🧩 Горизонтально. Второй рабочий сервер в том же кластере. Часть сеансов уходит на него. Сложнее в настройке, зато нагрузка делится.

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

Типовая схема для среднего предприятия:

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

Диагностика: логи, журнал и технологический журнал

Когда что-то идёт не так, начните с трёх источников.

Журнал регистрации. Фиксирует действия пользователей и ошибки на уровне базы. Подходит для вопроса «кто и что сделал».

Журнал событий ОС. Показывает, что происходило со службой агента: падения, остановки, ошибки запуска.

Технологический журнал. Это самый подробный источник. Он пишет вызовы, блокировки, запросы к СУБД, исключения. Включается файлом logcfg.xml в каталоге conf платформы. Пример минимального файла:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\techlog" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

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

Как искать причину по симптому:

Частые вопросы