Как правильно настроить MS SQL Server 2022/2025 для оптимальной работы с 1С:Предприятие

← На главную

Настройка системы управления базами данных — это фундамент производительности любой крупной информационной системы на базе 1С. С выходом версий MS SQL Server 2022 и 2025 многие старые рекомендации, которые системные администраторы использовали десятилетиями, стали неактуальными или требуют серьезного переосмысления. В этой статье мы подробно разберем, как адаптировать настройки современного SQL-сервера под специфику запросов 1С, проанализируем механизмы параллелизма и выясним, почему "золотая середина" сместилась в сторону более гибких параметров.

Настройка параллелизма: MAXDOP и современные реалии

Параметр Max Degree of Parallelism (MAXDOP) определяет максимальное количество ядер процессора, которые могут быть задействованы для выполнения одного запроса. Долгое время классической рекомендацией для 1С было установление этого параметра в значение 1. Это гарантировало отсутствие ожиданий на согласование потоков (CXPACKET), но лишало систему возможности ускорять тяжелые аналитические отчеты.

Рассмотрим, почему ситуация изменилась в версиях 2022/2025:

DOP Feedback (Обратная связь по степени параллелизма): В SQL Server 2022 появилась функция Intelligent Query Processing, которая самостоятельно анализирует выполнение запросов. Если сервер видит, что параллелизм вызывает избыточные задержки, он автоматически снижает степень параллелизма для конкретного проблемного запроса.
Рекомендация: На современных многоядерных серверах мы рекомендуем начинать со значения 8 (или количества ядер в одном NUMA-узле). Если база исключительно транзакционная (OLTP) и отчеты в ней практически не строятся, можно снизить значение до 4 или 2. Ставить 1 сегодня стоит только в исключительных случаях, когда движок 1С генерирует крайне неэффективные планы на специфических данных.

Настройка порога параллелизма: Cost Threshold for Parallelism

Параметр Cost Threshold for Parallelism (CTFP) указывает серверу, начиная с какой "стоимости" запроса (в условных единицах оптимизатора) стоит пытаться строить параллельный план. Разберем, почему стандартное значение 5 больше не подходит:

Значение "5" было актуально в конце 90-х годов. На современном железе с быстрыми процессорами и NVMe-дисками (например, KINGSTON SFYRD2000G) запрос стоимостью 5 выполняется мгновенно. Попытка распараллелить такой крошечный запрос тратит больше ресурсов на управление потоками, чем на саму работу. Это и приводит к появлению огромных ожиданий CXPACKET и CXCONSUMER.

Практический совет: Установите значение CTFP равным 50. Это позволит SQL Server использовать параллелизм только для действительно тяжелых запросов, оставляя простые операции на одном ядре. Это существенно снизит нагрузку на процессор и уберет "микро-фризы" у пользователей.

Управление процедурным кэшем и DBCC FREEPROCCACHE

Вопрос о том, нужно ли очищать процедурный кэш командой DBCC FREEPROCCACHE после ночного обслуживания (индексы, статистика), вызывает множество споров. Проанализируем ситуацию для версий 2022/2025:

В новых версиях SQL Server реализована технология PSP Optimization (Parameter Sensitive Plan). Теперь сервер умеет хранить несколько планов выполнения для одного запроса под разные наборы параметров. Это нивелирует главную проблему 1С — Parameter Sniffing.

Почему полная очистка кэша вредна:

При очистке сбрасываются накопленные данные Query Store и механизмов обратной связи (DOP Feedback, Memory Grant Feedback).
Первые часы после очистки сервер будет тратить ресурсы на перекомпиляцию всех планов, что вызовет общую просадку производительности.
Вместо полной очистки лучше использовать точечную рекомпиляцию таблиц, где статистика изменилась радикально:


-- Пример для конкретной таблицы, если это необходимо
EXEC sp_recompile 'ИмяТаблицы1С';

Оптимизация под разовые запросы (Ad Hoc Workloads)

Для 1С критически важно включить настройку optimize for ad hoc workloads. Особенности платформы 1С заключаются в генерации огромного количества уникальных SQL-запросов (из-за временных таблиц с рандомными именами). Без этой настройки процедурный кэш быстро забивается "мусором" — планами, которые никогда не будут использованы повторно.

Что это дает: При первом выполнении запроса SQL Server сохранит в кэше только небольшой "хэш" (stub), а не весь план целиком. Полноценный план будет сохранен только при повторном вызове того же запроса. Это экономит гигабайты оперативной памяти в буферном пуле.

Работа с TempDB в новых версиях

Поскольку 1С активно использует временные таблицы, нагрузка на tempdb всегда колоссальна. В SQL Server 2022 мы рекомендуем:

Включить Memory-optimized TempDB Metadata: Это переносит системные таблицы tempdb в память, устраняя затыки PAGELATCH на системных страницах.
Размещение: Как правильно отметил автор темы, использование NVMe дисков — отличное решение. Убедитесь, что количество файлов данных tempdb соответствует количеству логических процессоров (но не более 8, если только не наблюдается явная конкуренция).

Проверим текущие настройки конкуренции страниц можно следующим запросом:


SELECT wait_type, wait_time_ms, wait_resource
FROM sys.dm_os_waiting_tasks
WHERE wait_type LIKE 'PAGE%LATCH_%' AND resource_description LIKE '2:%';

Ускоренное восстановление (ADR)

Для баз 1С объемом более 500 ГБ обязательно рассмотрите включение Accelerated Database Recovery (ADR). В версиях 2022/2025 эта технология стала зрелой. Она позволяет мгновенно откатывать тяжелые транзакции (например, если аварийно завершилось перепроведение периода) и предотвращает бесконечный рост лога транзакций из-за одной "зависшей" сессии.

Итоги и "Золотая середина"

Подводя итог, для настройки MS SQL Server 2022/2025 под 1С на современном "железе" рекомендуем следующий стек параметров:

Max Degree of Parallelism: 8 (для начала, с мониторингом через Query Store).
Cost Threshold for Parallelism: 50.
Optimize for Ad Hoc Workloads: True.
Query Store: Включен (позволяет фиксировать хорошие планы и отслеживать регрессию).
DBCC FREEPROCCACHE: Исключить из регулярных регламентов обслуживания.

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