← На главную
Планирование серверных мощностей под СУБД Microsoft SQL Server для работы с платформой 1С:Предприятие — ответственная инженерная задача. Стоимость поядерного лицензирования СУБД (особенно редакции Enterprise) высока, поэтому избыточная закупка ядер ведет к неоправданным расходам, а их нехватка приводит к блокировкам и деградации производительности. Проанализируем методику расчета ядер процессора, принципы распределения нагрузки в 1С и варианты развертывания отказоустойчивых кластеров высокой доступности.
Методика расчета необходимого количества ядер СУБД
При расчете вычислительных ресурсов для транзакционной нагрузки (OLTP), характерной для 1С:Предприятия, не имеет смысла рассчитывать на то, что каждое дополнительное ядро ускорит выполнение единичной тяжелой операции. Выясним, по каким правилам и нормативам подбираются процессоры:
- Эмпирические нормы одновременных пользователей: В стандартных сценариях учетных систем ориентируются на следующие показатели: при легкой и средней нагрузке (просмотр отчетов, ввод типовых документов) выделяется 1 физическое ядро на 30–50 активно работающих пользователей. При интенсивной транзакционной нагрузке (массовое проведение документов, фоновые обмены, расчет себестоимости) норма составляет 1 физическое ядро на 15–25 активных сессий.
- Приоритет частоты ядра над их количеством: Архитектура платформы 1С такова, что большинство транзакционных цепочек выполняются последовательно в рамках одного потока. Поэтому высокая базовая и турбо-частота процессора (от 3.2–3.6 ГГц и выше) с высоким показателем производительности на ядро (IPC) дает значительно больший прирост быстродействия, чем установка многоядерного процессора с низкой частотой (например, 2.0–2.4 ГГц).
- Настройки параллелизма в MS SQL Server: По официальным рекомендациям фирмы «1С» параметр сервера СУБД
Max Degree of Parallelism (MAXDOP) рекомендуется устанавливать в значение 1. Это исключает параллельное исполнение отдельных запросов на нескольких ядрах, предотвращая взаимные блокировки потоков. В редких случаях для тяжелых баз данных значение параметра поднимают до 2–4, одновременно увеличивая порог Cost Threshold for Parallelism до 30–50. Из этого следует вывод: наращивание количества ядер позволяет обслуживать большее число параллельных пользователей, но не делает один конкретный запрос быстрее.
Метрики и диагностика дефицита процессорных ресурсов
Разберем по шагам, как определить, действительно ли СУБД испытывает дефицит ядер на текущей инфраструктуре:
- Длина очереди процессора (System\Processor Queue Length): Отслеживаем показатель в системном мониторе производительности (Performance Monitor). Если очередь потоков к процессору стабильно держится выше 2 на каждое физическое ядро — процессорных ресурсов недостаточно.
- Общая загрузка CPU (Processor(_Total)\% Processor Time): Средняя утилизация ядер в рабочие часы не должна превышать 60–70%. Оставшийся запас необходим для сглаживания пиковых нагрузок во время проведения регламентных процедур, закрытия месяца и пакетного ввода данных.
- Ожидания СУБД SOS_SCHEDULER_YIELD: Проанализируем статистику ожиданий в SQL Server. Высокая доля ожидания
SOS_SCHEDULER_YIELD в общем пуле системных ожиданий сигнализирует о том, что потоки добровольно уступают квант времени планировщику из-за нехватки свободных ядер.
Особенности построения отказоустойчивости Always On для 1С
При организации высокой доступности (High Availability) важно учитывать архитектурные ограничения платформы 1С и лицензионную политику СУБД:
- Basic Availability Groups в редакции Standard: Начиная с версии SQL Server 2016, редакция Standard поддерживает базовые группы доступности без общего дискового хранилища (Shared Storage). В отличие от классического отказоустойчивого кластера (FCI), здесь репликация идет на уровне базы данных между независимыми серверами. Ограничение редакции Standard — поддержка только одной базы в группе и наличие только двух узлов (основной и резервный), чего полностью достаточно для защиты рабочей базы 1С.
- Настройка сетевого слушателя (Listener): Кластер серверов 1С подключается к СУБД через виртуальное имя слушателя группы доступности. При настройке слушателя в мультисетевой конфигурации обязательно отключаем параметр
RegisterAllProvidersIP (устанавливаем значение 0). Это необходимо, так как стандартный клиентский стек платформы 1С не поддерживает асинхронный опрос подсетей MultiSubnetFailover, из-за чего при автоматическом переключении узлов могут возникать ошибки таймаута соединения рабочих процессов 1С. - Правила лицензирования пассивной реплики: По правилам лицензирования Microsoft при наличии активной подписки Software Assurance (SA) пассивный синхронный узел Always On для аварийного переключения (Failover) не требует лицензирования ядер, если на нем не выполняются пользовательские запросы на чтение и операции снятия резервных копий.
- Невозможность масштабирования чтения на вторичный узел: Платформа 1С:Предприятие архитектурно не разделяет транзакции на чтение и запись. Все запросы кластера 1С направляются исключительно на первичный узел, поэтому использование вторичных реплик Enterprise Always On в режиме
Read-Intent для типовых конфигураций невозможно без доработки кода на уровне внешних источников данных.
Альтернативные решения отказоустойчивости
Рассмотрим альтернативный вариант: если бюджет проекта не позволяет приобретать лицензии MS SQL Server с требуемым запасом ядер, надежную отказоустойчивую среду без общего хранилища можно развернуть на базе свободно распространяемой СУБД PostgreSQL или Postgres Pro. Отказоустойчивый кластер строится с использованием менеджера высокой доступности Patroni и распределенного хранилища состояний (etcd или Consul). Данный стек обеспечивает автоматический failover за несколько секунд и не накладывает лицензионных ограничений на число используемых процессорных ядер.