← На главную

Рассмотрим распространенную и крайне неприятную ситуацию: процесс sqlservr.exe на сервере начинает потреблять 70-100% ресурсов центрального процессора. Такая пиковая нагрузка может длиться по 10-15 минут, в результате чего система зависает, а у пользователей 1С начинают вылетать сеансы с ошибками или по таймауту. Разберем по шагам, как локализовать проблему, найти «виновника» и какие настройки СУБД и 1С помогут вернуть систему к нормальной работе.

Шаг 1. Диагностика: как найти проблемный запрос

Для начала выясним причину — какой именно запрос или процесс съедает ресурсы ЦП. Проанализируем доступные инструменты на уровне СУБД и 1С:

1. Мониторинг активности (Activity Monitor) в SQL Server Management Studio. Это базовый инструмент, в котором можно увидеть текущие выполняемые запросы. Нас интересуют запросы с наибольшим временем выполнения (параметр duration) или высоким потреблением CPU. Если запрос пришел из 1С, по именам таблиц (метаданных) в тексте SQL можно прикинуть, к какому объекту конфигурации идет обращение, и поискать проблему в коде.
2. Динамические административные представления (DMV). Вместо визуальных мониторов эффективнее использовать системные представления. Сделав запрос к sys.dm_exec_query_stats в соединении с sys.dm_exec_sql_text, мы сможем моментально получить ТОП тяжелых запросов, затративших наибольшее процессорное время.
3. Консоль администрирования серверов 1С. Посмотрим на сеансы пользователей прямо из 1С. В консоли можно отсортировать колонку Время вызова СУБД текущее. Если у кого-то из пользователей это время аномально большое, мы сразу поймем, кто запустил тяжелый отчет или обработку.
4. Технологический журнал 1С (ТЖ). Это самый точный метод диагностики. Настроив сбор ТЖ с фильтрами по событиям DBMSSQL, EXCP и CALL и ограничением по длительности (например, долгие запросы), мы получим точную строку кода и имя модуля в конфигурации 1С, откуда пришел тяжелый запрос. Текст сырого SQL-запроса зачастую слишком сложен для обратной расшифровки, а ТЖ дает прямой ответ.
5. Расширенные события (Extended Events). От использования устаревшего инструмента SQL Server Profiler лучше отказаться, так как полная трассировка сама по себе колоссально грузит сервер. Современная легковесная альтернатива от Microsoft — механизм Extended Events.

Шаг 2. Анализ причин высокой нагрузки

Если мы нашли проблемный запрос, проанализируем, почему именно он вызывает перегрузку. Рассмотрим самые частые причины в связке 1С и MS SQL Server:

Параллелизм выполнения запросов. По умолчанию SQL Server пытается распараллелить выполнение одного тяжелого запроса на все доступные ядра процессора (возникают ожидания типа CXPACKET). В результате один неоптимальный отчет или "кривой" запрос (например, анализ субконто за весь период без отборов) забирает 100% ЦП, полностью блокируя работу остальных пользователей.

Отсутствие необходимых индексов. Если 1С формирует запрос по полям, для которых в базе нет индексов, SQL Server вынужден выполнять полное сканирование таблиц (Table Scan или Clustered Index Scan). Перебор миллионов записей вызывает огромную нагрузку на процессор и дисковую подсистему.

Проблема Parameter Sniffing. СУБД кэширует план выполнения самого первого запроса под конкретные параметры. Когда запрос вызывается повторно с другими параметрами (для которых этот план неоптимален), сервер все равно использует старый алгоритм, что приводит к избыточным логическим чтениям и всплеску нагрузки.

Нехватка оперативной памяти (Buffer Pool Thrashing). Если SQL серверу не ограничить память, он может начать агрессивно забирать её у операционной системы. Когда памяти критически не хватает, начинается непрерывный сброс данных из кэша на диск и обратное их чтение. Процессор при этом загружается системными прерываниями и управлением памятью.

Шаг 3. Решения и оптимизация настроек

Рассмотрим практические шаги, которые необходимо предпринять для стабилизации работы сервера:

1. Настройка параметра MAXDOP. Это критически важная настройка для баз 1С. Необходимо ограничить параллелизм, установив параметр Максимальная степень параллелизма в значение 1. Это заставит запросы выполняться в один поток, не захватывая весь процессор. Также рекомендуется повысить значение Cost Threshold for Parallelism (например, до 50).
2. Ограничение потребления памяти. В свойствах MS SQL Server жестко задайте лимит Max Server Memory. Обязательно оставьте операционной системе и другим службам минимум 4–8 ГБ оперативной памяти (в зависимости от общего объема ОЗУ на сервере).
3. Регулярное обслуживание БД. Системе необходимо периодическое обслуживание. Настройте регламентные задания на ребилд (перестроение) индексов и обновление статистики. Обновление статистики и перестроение индексов сбрасывает закэшированные (и, возможно, неоптимальные) планы выполнения запросов, заставляя сервер строить их заново с учетом актуальных данных.
4. Проверка регламентных заданий 1С. Часто пики нагрузки связаны не с живыми пользователями, а с фоновыми заданиями 1С. Проверьте расписание выполнения тяжелых регламентных заданий (например, закрытие месяца, расчет себестоимости, обмен данными) — их лучше переносить на нерабочее время (ночью).
5. Разделение ролей серверов. Если служба сервера 1С (rphost) и процесс СУБД (sqlservr) работают на одном физическом или виртуальном сервере, они будут жестко конкурировать за процессорное время и оперативную память. Если есть возможность, разнесите сервер 1С и SQL Server на разные машины.

Применяя данные методы диагностики и базовые правила настройки связки MS SQL Server и 1С, вы сможете не только быстро найти причину 70-100% загрузки процессора, но и предотвратить подобные проблемы в будущем, обеспечив пользователям стабильную работу без «вылетов».