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

Диспетчер задач показывает: одно ядро процессора загружено на 100%, остальные 15 или 31 простаивают, а 1С при этом тормозит. Чаще всего причина в однопоточном характере конкретной операции — проведение документа, выполнение фонового задания или запрос к СУБД обрабатывается в одном потоке, и платформа физически не может разложить его по нескольким ядрам. Однако если нагрузка упирается в одно ядро постоянно даже при множестве активных пользователей, стоит проверить настройки кластера, ограничения лицензии и код конфигурации — проблема может быть в конфигурации, а не в архитектуре.

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

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

Архитектурная причина: один сеанс — один поток

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

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

Аналогично работает и СУБД: один SQL-запрос в MS SQL Server или PostgreSQL по умолчанию может выполняться последовательно. MS SQL умеет распараллеливать тяжёлые запросы (настраивается порогом cost threshold for parallelism), но для типичных коротких запросов 1С параллелизм чаще всего не включается.

Когда одно ядро — это норма, а когда симптом проблемы

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

Тревожный признак — одно ядро постоянно на 100% без видимой активности пользователей. Обычно это означает зависший цикл в коде, «бегающее» фоновое задание с ошибкой, блокировки, которые заставляют сеанс крутиться в ожидании, или проблему на стороне СУБД (например, неоптимальный план запроса, который сканирует миллионы строк).

Как диагностировать, что именно грузит ядро

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

Второй шаг — включить технологический журнал (ТЖ) с событиями DBMSSQL/DBPOSTGRS и EXCP с фильтром по длительности. ТЖ покажет конкретные запросы и контексты кода, которые выполняются дольше заданного порога. Это самый прямой способ найти «виновника» без догадок.

Третий шаг — посмотреть на сторону СУБД. В MS SQL Server используйте представления sys.dm_exec_requests и sys.dm_exec_query_stats, чтобы найти запросы с максимальным потреблением CPU. В PostgreSQL — pg_stat_statements. Если тяжёлый запрос найден, дальше работа идёт с его планом: нехватка индекса, устаревшая статистика, сканирование вместо поиска.

1. 1
   Откройте мониторинг ресурсов и зафиксируйте, какой процесс грузит ядро: rphost, sqlservr/postgres или 1cv8 (файловый режим)
2. 2
   В консоли кластера найдите активный сеанс или фоновое задание, совпадающее по времени с нагрузкой
3. 3
   Включите технологический журнал с порогом длительности, например события дольше 3–5 секунд
4. 4
   Найдите в ТЖ длительные запросы и контекст кода, который их вызвал
5. 5
   Проверьте план проблемного запроса в СУБД: сканирования, отсутствующие индексы, устаревшая статистика
6. 6
   После исправления повторите замер длительности операции и загрузки ядра

Что реально ускоряет однопоточную работу

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

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

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

Способы ускорения

Процессор с высокой частотой

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

Оптимизация запросов и кода

Даёт максимальный эффект при выявленных узких местах. Требует доступа к конфигурации и навыков разработки

Фоновые задания и порционная обработка

Подходит для обменов, загрузок, групповых обработок. Не ускоряет интерактивные действия пользователя

Настройка СУБД (индексы, статистика, память)

Эффективна при тяжёлых запросах. Требует аккуратности: лишние индексы замедляют запись

Настройки сервера 1С и СУБД, влияющие на загрузку ядер

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

На стороне MS SQL Server проверьте параметр max degree of parallelism (MAXDOP) и cost threshold for parallelism. Для баз 1С часто рекомендуют ограничивать MAXDOP и повышать порог стоимости, чтобы короткие запросы не распараллеливались без нужды, а параллелились только действительно тяжёлые. Универсальных значений нет — подбирайте под свою нагрузку и фиксируйте эффект замерами.

Также проверьте режим электропитания сервера: схема «Экономия энергии» в Windows или агрессивное управление частотой в BIOS снижает тактовую частоту ядер и напрямую замедляет однопоточный код. Для серверов 1С и СУБД рекомендуется схема «Высокая производительность».

Файловый режим: почему там всё ещё хуже

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

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

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

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

Контрольные точки

Как проверить результат

Длительность целевой операции до и после изменений

Норма

Время сократилось при той же нагрузке

Тревожный признак

Время не изменилось или выросло — изменение не попало в узкое место

Загрузка ядер под многопользовательской нагрузкой

Норма

Нагрузка распределена по нескольким ядрам и процессам

Тревожный признак

Все сеансы по-прежнему стоят в очереди к одному процессу

Технологический журнал

Норма

Длительные события исчезли или сократились

Тревожный признак

Те же запросы с той же длительностью

Ожидания на блокировках

Норма

Ожидания редки и коротки

Тревожный признак

Долгие ожидания — проблема в блокировках, а не в CPU

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

Можно ли заставить 1С использовать несколько ядер для одного отчёта?

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

Почему на мощном сервере 1С медленнее, чем на старом, но с более высокой частотой CPU?

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

Одно ядро загружено на 100% ночью, когда никто не работает. Что это?

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

Поможет ли увеличение оперативной памяти, если грузится одно ядро?

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

Это проблема конкретной конфигурации или платформы в целом?

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