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

Администраторы часто замечают характерную картину: сервер мощный, ядер много, а процесс rphost или 1cv8.exe упирается в загрузку одного ядра на 100%, остальные простаивают. Пользователи при этом жалуются на «тормоза», проведение документов занимает минуты, а отчёты формируются бесконечно долго. Это не неисправность оборудования и не ошибка настройки Windows — такое поведение заложено в архитектуре платформы и в природе большинства учётных задач.

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

Вторая причина — СУБД. Значительная часть «тяжёлой» работы 1С — это запросы к базе данных, а один запрос в MS SQL Server или PostgreSQL по умолчанию тоже может выполняться одним потоком. Если запрос не распараллелен оптимизатором СУБД, всё упирается в одно ядро уже на стороне базы данных. Поэтому картина «одно ядро на 100%» может наблюдаться как на сервере 1С, так и на сервере СУБД — и причины в каждом случае разные.

Как устроено исполнение кода 1С и почему сеанс занимает одно ядро

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

Это справедливо как для файлового, так и для клиент-серверного режима. В файловом варианте вся работа выполняется в процессе клиентского приложения (1cv8.exe) на компьютере пользователя. В клиент-серверном — в рабочем процессе rphost на сервере 1С. В обоих случаях один сеанс — один активный поток в конкретный момент времени.

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

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

Первый шаг — определить, какой процесс создаёт нагрузку. Откройте диспетчер задач на вкладке «Подробности», добавьте столбцы и посмотрите, кто потребляет процессор: 1cv8.exe (клиент), rphost (сервер 1С) или sqlservr.exe / postgres (СУБД). Чтобы увидеть загрузку по ядрам, на вкладке «Производительность» переключите график процессора в режим отображения логических процессоров.

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

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

Почему сервер с большим числом ядер не ускоряет 1С

Добавление ядер помогает только тогда, когда есть параллельная нагрузка: много одновременных сеансов, несколько рабочих процессов, фоновые задания. Если на сервере работает один пользователь, который проводит тяжёлый документ, то 32-ядерный сервер будет работать не быстрее 4-ядерного с той же архитектурой — задействовано всё равно одно ядро.

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

Ещё один нюанс виртуализации: на виртуальной машине производительность ядра может заметно отличаться от физического из-за политик гипервизора, ограничений (limit/reservation) и режима энергосбережения хоста. Прежде чем менять конфигурацию, убедитесь, что виртуальная машина реально получает заявленную частоту.

Настройка кластера 1С: как распределить нагрузку по ядрам

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

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

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

1. 1
   В консоли кластера определите перегруженный рабочий процесс и число сеансов на нём
2. 2
   Проверьте настройки рабочего сервера: число процессов и лимиты соединений на процесс
3. 3
   Увеличьте количество рабочих процессов с учётом доступной оперативной памяти
4. 4
   Перезапустите службу сервера 1С и проконтролируйте распределение сеансов
5. 5
   Сравните загрузку ядер и время отклика до и после изменения

Роль СУБД: почему SQL тоже работает в один поток

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

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

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

Что можно сделать на уровне конфигурации и кода

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

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

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

Когда и как переходить к оптимизации: маршрут действий

Рациональная последовательность такова: сначала локализовать процесс (клиент, rphost, СУБД), затем найти конкретную операцию и запрос, после этого выбрать точечное средство — индекс, переписывание запроса, настройка параллелизма СУБД, перераспределение сеансов по рабочим процессам или вынос операции в фоновое задание. Апгрейд оборудования — последний шаг, когда точно доказано, что узкое место в однопоточной производительности процессора.

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

Маршрут решения

Как выбрать действие

Один сеанс долго выполняет операцию, грузится rphostИщите узкое место в коде через технологический журнал и оптимизируйте запросы

Грузится процесс СУБД одним ядромАнализируйте план запроса, индексы и настройки параллелизма СУБД

Много пользователей, сеансы копятся на одном rphostУвеличивайте число рабочих процессов и настраивайте распределение сеансов

Все ядра загружены равномерно, но работа медленнаяПроверяйте диски, память, сеть и блокировки — процессор не является узким местом

Файловый режим и медленный клиентский ПКРассмотрите переход на клиент-серверный вариант или обновление локального оборудования

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

Поможет ли 1С переход на процессор с большим числом ядер?

Только если нагрузка параллельная: много одновременных пользователей и фоновых заданий. Для ускорения конкретной операции важнее частота ядра и однопоточная производительность. Сервер с меньшим числом высокочастотных ядер часто оказывается для 1С выгоднее многоядерного низкочастотного.

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

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

Одно ядро загружено на 100% — это признак неисправности?

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

Почему в файловом режиме 1С особенно медленная?

В файловом варианте вся работа выполняется на компьютере пользователя, а доступ к данным идёт через файловую систему или сетевой диск, что добавляет задержки. Многопользовательская работа в файловом режиме дополнительно ограничена механизмом блокировок. При росте базы и числа пользователей рекомендуется переход на клиент-серверную архитектуру.

Какие настройки SQL Server важны для параллелизма запросов 1С?

Ключевые — cost threshold for parallelism и max degree of parallelism: первый определяет, какие запросы допускаются к распараллеливанию, второй ограничивает число потоков на запрос. Значения подбираются под нагрузку; перед изменением зафиксируйте текущие параметры и замерьте время типовых операций до и после.

Как понять, что проблема не в процессоре, а в дисках или блокировках?

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