Сервер 1С Предприятие изнутри: из каких процессов он состоит и как их настроить

Сервер 1С Предприятия — это не одна программа, а набор процессов. Агент ragent стартует службу, менеджер кластера rmngr раздаёт работу, рабочие процессы rphost исполняют код конфигурации и ходят в СУБД. Клиент подключается к кластеру, а не к «серверу вообще».

Данные при этом хранит не 1С, а PostgreSQL, MS SQL Server или другая поддерживаемая СУБД. Сервер 1С держит бизнес-логику, сеансы, блокировки и кеши. Ниже — как эти части связаны и что в них можно крутить.

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

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

Основные участники:

• ⚙️ Агент сервера (ragent) — служба, которую запускает операционная система. Она следит за кластерами на машине и поднимает остальные процессы.
• 🧭 Менеджер кластера (rmngr) — «диспетчер». Хранит список сеансов и баз, распределяет клиентов по рабочим процессам, управляет блокировками.
• 🛠 Рабочий процесс (rphost) — здесь выполняется серверный код конфигурации и идёт обмен с СУБД. Именно он «ест» память и процессор.
• 🖥 Сервер администрирования (ras) — по желанию. Через него консоль и утилита rac управляют кластером.

Один рабочий сервер может быть одновременно главным (там живёт менеджер кластера, который считается «главным» в кластере) и обычным рабочим. В схеме с несколькими машинами главный менеджер остаётся один, а рабочих процессов становится больше.

Что хранится в каталоге кластера

В srvinfo лежит список баз, настройки кластера, администраторы кластера и служебные данные сеансов. Сами таблицы базы — в СУБД. Потеряете каталог — потеряете регистрацию баз в кластере (но не данные), поэтому его включают в резервное копирование наравне с серверной базой.

Как живёт рабочий процесс rphost

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

Путь запроса пользователя:

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

Один rphost способен обслуживать десятки сеансов. Сколько именно — решают настройки кластера.

Параметры, которые влияют на перезапуск

В свойствах рабочего сервера и кластера (консоль администрирования серверов 1С, раздел «Кластеры») есть несколько настроек, которые определяют судьбу процесса:

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

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

Один процесс на базу или общий

Режим «много баз в одном процессе» экономит память, но сбой в одной базе заденет соседей. Для критичных баз (учёт, торговля) часто выделяют отдельные процессы, для мелких тестовых — делят один. Это решается значением «Количество информационных баз на процесс».

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

Рабочий процесс — единственный, кто говорит с СУБД. Клиент в базу напрямую не ходит. Конфигурация 1С формирует запрос на встроенном языке, rphost превращает его в SQL и отправляет на сервер баз данных.

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

• 🔗 Сервер 1С и СУБД лучше держать в одной быстрой сети. Задержка между ними умножается на тысячи обращений в минуту.
• 🧱 Блокировки данных — две ступени. Управляемые блокировки (которые видит и контролирует 1С) обслуживает менеджер кластера. Блокировки СУБД ставит сам SQL-сервер. Конфликт на любой из них даёт ожидание или ошибку.
• 📦 Одну базу 1С нельзя «разнести» по нескольким СУБД: она живёт в одной.
• 🧮 Размер памяти СУБД и памяти 1С конкурируют, если они на одной машине. Для PostgreSQL и MS SQL лимиты памяти задавайте явно, чтобы СУБД не вытеснила rphost из оперативки.

Что сервер 1С держит у себя

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

Порты и сетевое взаимодействие

Сервер 1С по умолчанию использует такие порты:

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

Что нужно открыть в брандмауэре, если клиенты в другой сети:

1. Порт агента и порт менеджера кластера.
2. Весь диапазон рабочих процессов — клиент после первого обращения идёт напрямую в rphost.
3. Порт СУБД между сервером 1С и сервером баз (для PostgreSQL по умолчанию 5432, для MS SQL Server — 1433). С клиентских машин его открывать не нужно.

Типичная ошибка: открыли только 1540 и 1541, а диапазон рабочих процессов закрыт. Клиент подключается к кластеру, но сеанс не открывается или обрывается. Проверка простая: с клиента выполните проверку порта (Test-NetConnection в PowerShell) для 1540, 1541 и любого порта из диапазона 1560–1591.

Подключение клиентов

Тонкий и толстый клиент указывают адрес в формате имя_сервера:порт_агента и имя базы. Если порт по умолчанию, достаточно имени сервера. Веб-клиент и HTTP-сервисы идут через веб-сервер (IIS, Apache), а он уже обращается к кластеру теми же портами.

Как понять, что сервер перегружен

Жалоба «1С тормозит» ничего не говорит. Нужно найти узкое место: процессор, память, диск, СУБД или блокировки.

Порядок проверки:

1. Диспетчер задач или htop. Посмотрите, какой процесс занимает процессор: rphost или процесс СУБД. Это сразу делит проблему на «код 1С» и «запросы/диск».
2. Консоль кластера. В списке рабочих процессов видно память, число соединений и нагрузку каждого. Один процесс раздулся — ищите тяжёлый сеанс. Все равномерно загружены — не хватает ресурсов.
3. Сеансы и блокировки. В консоли у каждого сеанса есть текущий вызов и время его выполнения. Долгие вызовы — кандидаты на оптимизацию.
4. Замер производительности. В платформе есть встроенный механизм замеров ключевых операций. Он показывает, какая операция стала медленнее и насколько.
5. Технологический журнал. Настраивается файлом logcfg.xml в каталоге conf платформы. Пишет события вплоть до отдельных запросов, ожиданий на блокировках и исключений.

Какие признаки о чём говорят

• 🔥 rphost на 100% процессора при низкой нагрузке СУБД — тяжёлый серверный код или цикл по записям в 1С.
• 💾 Высокая нагрузка СУБД и очередь к диску — медленные запросы, нет индексов, мало памяти у СУБД.
• ⏳ Процессор свободен, а пользователи ждут — смотрите блокировки: управляемые и на уровне СУБД.
• 📈 Память rphost растёт между перезапусками — проверьте интервал перезапуска и допустимый объём.

Для крупных систем есть отдельный продукт «Центр управления производительностью», он собирает такую статистику постоянно. Для небольшой базы хватает консоли кластера и замера.

Настройка сервера 1С под вашу нагрузку

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

Что проверить перед началом

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

Рабочие шаги

1. Определите, сколько сеансов приходится на один процесс сейчас. Если один процесс держит сотни соединений, нагрузка не масштабируется.
2. Задайте разумное количество соединений на процесс, чтобы процессов было несколько, но не десятки. Обычно начинают с умеренного значения и корректируют по замерам.
3. Установите допустимый объём памяти рабочего процесса так, чтобы суммарно по всем процессам он не превышал свободную оперативную память.
4. Поставьте периодический перезапуск (например, раз в несколько часов, ночью — чаще не нужно).
5. Отделите тяжёлые регламентные задания: их можно вынести на отдельный рабочий сервер или отдельную базу.
6. Через неделю сравните замеры с исходными.

Пример прикидки по памяти. Сервер с 32 ГБ, из них 12 ГБ отдаём PostgreSQL, 4 ГБ — системе. На 1С остаётся 16 ГБ. Если рабочих процессов четыре, на каждый можно планировать не более 4 ГБ. Если процесс регулярно упирается в лимит, это сигнал искать причину в коде, а не просто поднимать цифру.

Когда нужен второй сервер

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

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