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

1С загружает одно ядро на 100 % при общей загрузке процессора 5–10 %, потому что большинство операций платформы — проведение документа, закрытие месяца, формирование отчёта — выполняются в одном потоке и физически не могут быть распределены между ядрами. Сервер с 16 или 32 ядрами в этот момент простаивает, пользователи жалуются на «тормоза», а диспетчер задач показывает, что работает лишь один поток rphost. Это не ошибка установки и не дефект железа, а следствие архитектуры платформы: ускорить такую задачу можно более производительным ядром и оптимизацией кода, но не добавлением новых ядер.

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

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

Как устроено выполнение кода в платформе 1С

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

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

Где именно возникает «узкое место» одного ядра

Чаще всего жалобы возникают на типовых сценариях: тяжёлые отчёты за большой период, групповое перепроведение документов, расчёт себестоимости или зарплаты, обмены данными, загрузка больших файлов. Во всех этих случаях один сеанс выполняет длительную последовательную работу, и в диспетчере задач видно характерную картину: один логический процессор на 100 %, остальные почти свободны.

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

Роль сервера 1С и рабочих процессов

В клиент-серверном варианте нагрузку обслуживают рабочие процессы rphost. Каждый процесс может обслуживать несколько сеансов, но один сеанс в момент выполнения операции занимает один поток. Если рабочий процесс один, а сеансов много, возникают очереди внутри процесса — и снова видна картина «одного занятого ядра».

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

1. 1
   Откройте диспетчер задач или монитор ресурсов и посмотрите загрузку по каждому ядру отдельно, а не среднюю
2. 2
   Определите, какой процесс грузит ядро: rphost, sqlservr, 1cv8 (клиент) или фоновое задание
3. 3
   В консоли кластера найдите сеанс, которому принадлежит нагрузка, и выясните выполняемую операцию
4. 4
   Зафиксируйте время выполнения операции до внесения изменений — это точка отсчёта для проверки эффекта

Настройки СУБД: где реально задействовать несколько ядер

Значительная часть тяжёлой работы в клиент-серверной 1С выполняется на стороне СУБД. MS SQL Server умеет распараллеливать запросы, но делает это по внутренним порогам стоимости: дешёвые запросы выполняются одним потоком. Параметры «max degree of parallelism» и «cost threshold for parallelism» определяют, когда запрос разбивается на несколько потоков.

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

Что реально ускоряет однопоточные операции

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

Второй фактор — дисковая подсистема и память. Если операция постоянно читает данные с диска, процессор простаивает в ожидании, и даже одно ядро загружено не полностью. Быстрые NVMe-диски и достаточный объём ОЗУ под кэш СУБД часто дают больший эффект, чем замена процессора.

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

Как распараллелить работу штатными средствами

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

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

// Запуск фонового задания из кода 1С
ПараметрыЗадания = Новый Массив;
ПараметрыЗадания.Добавить(НачалоПериода);
ПараметрыЗадания.Добавить(КонецПериода);
Задание = ФоновыеЗадания.Выполнить("ОбработкаДанных.ОбработатьПорцию", ПараметрыЗадания, КлючЗадания, "Обработка порции данных");

Типичные ошибки при борьбе с «одним ядром»

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

Вторая ошибка — попытка ускорить работу настройками без диагностики. Без замера невозможно понять, где время: в процессоре, диске, блокировках или коде. Третья ошибка — игнорирование блокировок: иногда «одно ядро на 100 %» у одного сеанса сопровождается ожиданием остальных, и реальная причина медлительности — не процессор, а конкуренция за данные.

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

Любое изменение — настройки СУБД, железо, доработку кода — оценивайте по одному и тому же сценарию: одна и та же операция, одинаковый объём данных, сопоставимая фоновая нагрузка. Замеряйте время выполнения до и после. Разовый замер ненадёжен: делайте несколько прогонов и смотрите среднее.

Полезно наблюдать и загрузку ядер: если после разбиения задачи на фоновые задания во время операции работают уже 4–6 ядер вместо одного, а общее время сократилось — распараллеливание сработало. Если ядер стало больше, а время не изменилось — узкое место переехало, например, на диск или блокировки.

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