Сколько ядер использует сервер 1С и как это проверить

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

Именно поэтому администраторы часто видят картину: на сервере 32 ядра, загрузка CPU по мониторингу — 10–15%, а пользователи жалуются на «тормоза». Причина в том, что конкретный сеанс обслуживается одним рабочим процессом, и его скорость упирается в производительность одного потока, а не в суммарную мощность всех ядер. Понимание этой архитектуры — ключ к правильной настройке кластера и выбору оборудования.

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

Как сервер 1С работает с ядрами процессора

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

Внутри одного rphost выполнение серверного кода в основном последовательное для конкретного сеанса: пока процесс выполняет один запрос пользователя, он занят им. Платформа умеет обслуживать несколько сеансов в одном процессе за счёт внутренней многопоточности, но пиковая нагрузка одного процесса редко равномерно распределяется больше чем на несколько ядер. Часть работы (запросы к СУБД) вообще выполняется на стороне SQL-сервера, а не на сервере 1С.

Практический вывод: общая утилизация ядер сервера 1С определяется произведением «число активных рабочих процессов × нагрузка каждого». Если rphost один, а пользователей сто, часть сеансов будет ждать очереди внутри процесса, а остальные ядра сервера будут простаивать.

Сколько ядер реально нагружает один сеанс и один процесс

Активный пользовательский сеанс в момент выполнения операции (например, проведения документа) создаёт нагрузку примерно на один поток исполнения на сервере 1С плюс нагрузку на СУБД. То есть один интенсивно работающий пользователь «съедает» условно одно ядро на сервере приложений и ещё ресурсы на SQL-сервере.

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

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

Настройка количества рабочих процессов и распределения нагрузки

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

Ориентировочная логика подбора: количество rphost стоит связывать с числом физических ядер и объёмом памяти, а не с числом пользователей напрямую. На практике часто используют несколько процессов на сервер (например, по одному на 2–4 ядра при достаточном объёме RAM), чтобы и ядра были заняты, и память не была фрагментирована. Точные цифры зависят от конфигурации, профиля нагрузки и версии платформы — универсальной формулы нет, параметры подбираются по мониторингу.

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

1. 1
   Откройте консоль администрирования кластера и посмотрите текущее число рабочих процессов и сеансов на каждый
2. 2
   Зафиксируйте базовые метрики: загрузку CPU по процессам, память, время отклика у пользователей
3. 3
   Установите ограничение на число сеансов/баз на процесс, чтобы кластер создавал дополнительные rphost
4. 4
   Перезапустите нагрузку (или дождитесь рабочего дня) и снимите метрики повторно
5. 5
   Скорректируйте параметры по результатам: добавьте процессы при простаивающих ядрах или уменьшите при нехватке памяти

Как проверить фактическое использование ядер

На Windows используйте диспетчер задач или Process Explorer: отфильтруйте процессы rphost и смотрите загрузку CPU каждого в отдельности, а также общую загрузку по ядрам (представление «логические процессоры»). Если один rphost держит высокий процент, а остальные простаивают — сеансы распределены неравномерно.

На Linux удобны top (с включённым отображением по ядрам — клавиша «1») и htop. Для детального анализа по процессам:

top -b -n 1 | grep rphost
# или по ядрам:
mpstat -P ALL 2 5

Не забывайте смотреть не только CPU, но и ожидания ввода-вывода (iowait): высокий iowait при низком CPU означает, что процессор простаивает в ожидании дисков, и добавление процессов или ядер проблему не решит. Дополнительно используйте технологический журнал платформы и счётчики производительности СУБД — они покажут, где именно тратится время: на сервере 1С или на запросах к базе.

Выбор процессора: частота важнее числа ядер

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

Много ядер оправдано при большом числе одновременных пользователей, параллельных фоновых заданиях и совмещении ролей (сервер 1С + СУБД на одной машине — что, впрочем, для нагруженных систем не рекомендуется). Для десятков активных сеансов хватает умеренного числа быстрых ядер; сотни одновременных пользователей уже требуют и масштабирования по процессам, и, возможно, нескольких рабочих серверов в кластере.

Типичные ошибки и ограничения

Самая частая ошибка — судить о производительности по общей загрузке CPU. Низкий процент загрузки не означает, что «серверу хватает мощности»: возможно, нагрузка просто не распараллелена, а пользователи стоят в очереди внутри одного процесса. Оценивать нужно отклик операций и загрузку каждого rphost в отдельности.

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

Третья ошибка — игнорирование СУБД. Значительная часть «медленной» работы 1С — это запросы к базе данных, блокировки и нехватка ресурсов на SQL-сервере. Настройка ядер сервера 1С в этом случае эффекта не даст.

FAQ