Что делать, если SQL Server грузит процессор на 100% при работе с 1С

Перенос критически важных баз данных 1С на новое окружение — это всегда ответственный шаг. Нередко системные администраторы сталкиваются с неприятной ситуацией: после миграции связки 1С и СУБД на современную операционную систему Windows Server 2016 и MS SQL Server 2016 (например, со старых версий Windows Server 2012 R2 и SQL Server 2008) сервер начинает вести себя крайне нестабильно. Процессор уходит в глухую сотню процентов загрузки, пользователи жалуются на постоянные взаимоблокировки (дедлоки), а сессии аварийно завершаются.

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

Шаг 1. Анализ статистики ожиданий (Wait Statistics)

Прежде чем менять какие-либо настройки вслепую, нам необходимо понять, чем именно занят процессор нашего SQL-сервера. Для этого проанализируем системное представление динамического управления. Выполним сбор статистики ожиданий СУБД. Начнем мониторинг с очистки текущих показателей, подождем некоторое время (желательно в период активной работы пользователей) и выведем результат на экран.

Запустим в СУБД следующий SQL-скрипт:

-- Обнуляем представление системной статистики ожиданий перед тестом
DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR);

-- Ждем некоторое время (например, час или два), после чего выполняем запрос:
SELECT * 
FROM sys.dm_os_wait_stats 
WHERE wait_time_ms > 0
ORDER BY wait_time_ms DESC;

Внимательно проанализируем полученную таблицу. Если на первых местах по времени ожидания (wait_time_ms) находятся показатели типа CXPACKET или CXCONSUMER, это верный признак проблем с параллелизмом. Если мы видим высокие значения по ожиданиям PAGEIOLATCH_SH или PAGEIOLATCH_EX, проблема кроется в медленном чтении данных с жестких дисков в оперативную память. Ожидания типа LCK_M_... укажут на классические блокировки на уровне таблиц СУБД.

Шаг 2. Настройка параллелизма (MAXDOP) и порога стоимости

По умолчанию при установке MS SQL Server параметр максимальной степени параллелизма (Max Degree of Parallelism - MAXDOP) равен 0. Это означает, что для выполнения одного тяжелого запроса СУБД может использовать абсолютно все доступные ядра процессора. Запросы, генерируемые платформой 1С:Предприятие, часто бывают сложными и вложенными. В результате один неоптимальный запрос пользователя может полностью монополизировать все ядра слабого процессора (например, Xeon E5-2620v2 с базовой частотой 2.1 ГГц).

Для оптимизации работы СУБД под задачи 1С рекомендуется принудительно ограничить параллелизм:

1. Откроем СУБД через SQL Server Management Studio (SSMS).
2. Кликнем правой кнопкой мыши по имени сервера и перейдем в Properties (Свойства).
3. Перейдем на вкладку Advanced (Дополнительно).
4. Найдем параметр Max Degree of Parallelism и установим его значение равным 1 (для баз с высокой частотой коротких транзакций) или 2 (если ядер на сервере много, например, более 16). Значение 1 полностью отключает параллелизм для отдельных запросов, гарантируя, что один кривой отчет не положит всю систему.
5. Параметр Cost Threshold for Parallelism (Порог стоимости для параллелизма) по умолчанию равен 5. Это слишком мало. Изменим его значение на 50, чтобы мелкие запросы гарантированно обрабатывались на одном ядре.

Шаг 3. Включение режима Read Committed Snapshot Isolation (RCSI)

Стандартный механизм блокировок MS SQL Server при уровне изоляции транзакций по умолчанию заставляет пишущие транзакции блокировать читающие, и наоборот. В многопользовательской среде 1С это моментально приводит к дедлокам и росту очереди к процессору. Включение механизма версионирования строк (RCSI) позволяет пользователям читать данные без наложения блокировок на таблицы, используя временное хранилище в базе tempdb.

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

USE master;
GO
ALTER DATABASE [Имя_Вашей_Базы_1С] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
ALTER DATABASE [Имя_Вашей_Базы_1С] SET READ_COMMITTED_SNAPSHOT ON;
GO
ALTER DATABASE [Имя_Вашей_Базы_1С] SET MULTI_USER;
GO

Шаг 4. Возврат к старому оценщику кардинальности (Cardinality Estimator)

Начиная с версии SQL Server 2014, Microsoft внедрила новый алгоритм оценки количества строк (кардинальности) для построения планов запросов. Специфика архитектуры метаданных 1С такова, что новый оптимизатор SQL Server 2016 часто ошибается, выбирая крайне неэффективные планы выполнения (например, сканирование всей таблицы вместо быстрого поиска по индексу). Это моментально нагружает процессор на 100%.

Для решения этой проблемы вернем использование старого (Legacy) оптимизатора запросов. Мы можем сделать это прямо в свойствах конкретной базы данных без изменения глобальных настроек инстанса:

USE [Имя_Вашей_Базы_1С];
GO
ALTER DATABASE SCOPED CONFIGURATION SET LEGACY_CARDINALITY_ESTIMATOR = ON;
GO

Также мы можем изменить уровень совместимости базы данных (Compatibility Level) на SQL Server 2012 (110) или SQL Server 2008 (100) в свойствах базы данных на вкладке Options.

Шаг 5. Настройка схемы электропитания в Windows и BIOS

Современные процессоры Intel Xeon по умолчанию работают по схемам энергосбережения. Частота процессора динамически падает при отсутствии нагрузки. Однако 1С генерирует миллионы мелких запросов, на которые процессор в режиме "Сбалансированный" просто не успевает повышать частоту, продолжая работать на минимальных 1.2 ГГц вместо положенных 2.5 ГГц или выше.

Выполним жесткую настройку производительности на уровне операционной системы и аппаратной платформы:

1. В операционной системе Windows Server 2016 зайдем в Панель управления -> Электропитание и выберем схему Высокая производительность (High Performance). В дополнительных параметрах убедимся, что минимальное состояние процессора установлено в 100%.
2. Перезагрузим физический сервер, зайдем в BIOS (для серверов HP это клавиша F9 при старте).
3. Перейдем в раздел Power Management и переключим параметр Power Regulator в режим Static High Performance (Максимальная производительность).
4. Отключим технологии энергосбережения процессора: Intel SpeedStep и C-States / C1E (переведем в состояние Disabled).

Шаг 6. Отключение службы динамического распределения ресурсов (DFSS)

Если на одном физическом сервере у нас развернуты СУБД MS SQL, сервер приложений 1С и терминальный сервер (RemoteApp), операционная система Windows Server 2016 по умолчанию активирует функцию распределения ресурсов Dynamic Fair Share Scheduling (DFSS). Эта служба принудительно урезает процессорное время и дисковый ввод-вывод для фоновых служб (которыми она считает SQL Server и процессы rphost) в пользу активных сессий терминальных пользователей. Это вызывает колоссальные задержки.

Отключим данный механизм через системный реестр. Откроем командную строку от имени администратора и выполним следующие команды:

reg add "HKLM\System\CurrentControlSet\Services\TSFairShare" /v EnableDynamicFairShare /t REG_DWORD /d 0 /f
reg add "HKLM\System\CurrentControlSet\Services\TSFairShare\Disk" /v EnableDynamicFairShare /t REG_DWORD /d 0 /f

После внесения изменений в реестр обязательно перезагрузим операционную систему сервера.

Шаг 7. Включение мгновенной инициализации файлов (Instant File Initialization)

Когда база данных 1С увеличивается в размерах, СУБД запрашивает у операционной системы новое место на диске. По умолчанию Windows забивает выделенный кусок диска нулями, полностью блокируя запись в базу на этот период. На медленных дисковых массивах (например, RAID 5 из дисков SAS 10k) этот процесс вызывает долгое зависание 1С и резкий скачок нагрузки на процессор.

Разрешим SQL-серверу мгновенно выделять место на диске:

1. Нажмем комбинацию клавиш Win + R, введем secpol.msc и нажмем Enter для открытия локальной политики безопасности.
2. Перейдем по пути: Локальные политики -> Назначение прав пользователя.
3. Найдем политику Выполнение задач по обслуживанию томов (Perform volume maintenance tasks).
4. Дважды кликнем по ней и добавим учетную запись, под которой запущена служба SQL Server (например, NT Service\MSSQLSERVER).
5. Перезапустим службу SQL Server для применения настроек.

Шаг 8. Оптимизация дисковой подсистемы и использование Shared Memory

Размещение базы данных, файлов логов транзакций и системной базы tempdb на одном логическом диске, созданном поверх массива RAID 5 из обычных жестких дисков (HDD), является критической архитектурной ошибкой. Даже если эти файлы разнесены по разным буквам дисков (C, D, E), физически головки дисков выполняют случайное чтение в одной области, создавая огромную очередь диска.

Проанализируем наши возможности по оптимизации ввода-вывода:

• Настоятельно рекомендуется приобрести хотя бы два производительных SSD-диска (даже потребительского класса SATA SSD в зеркальном RAID 1, если бюджет ограничен) для размещения файлов базы данных 1С и файлов tempdb. Логи транзакций при этом можно оставить на HDD-массиве.
• Поскольку сервер 1С и СУБД работают на одной физической машине, настроим сетевой протокол обмена. В утилите SQL Server Configuration Manager перейдем в раздел SQL Server Network Configuration -> Protocols for MSSQLSERVER и убедимся, что протокол Shared Memory (Общая память) включен. Это позволит процессам 1С общаться с СУБД напрямую через оперативную память, минуя сетевой стек TCP/IP, что существенно разгрузит центральный процессор.

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