Пользователи уже ждут проведения документов, а SQL Server не сообщает об ошибках. Администратор открывает диспетчер задач, видит загрузку процессора и начинает менять настройки наугад.
Жалобы сотрудников часто становятся первым признаком снижения производительности SQL Server. На это указывает руководство Грега Робидо «SQL Server Performance Tuning and Monitoring Tutorial». Но жалоба «1С тормозит» не показывает причину. Нужна базовая точка, с которой вы сравните состояние сервера после правки.
Задача на первый день — не подобрать универсальные значения MAXDOP или размер tempdb. Сначала настройте наблюдение, найдите участок задержки и измените один параметр. Затем повторите тот же рабочий сценарий.
Выберите две метрики, которые видит пользователь
Microsoft Learn определяет время отклика как интервал до появления первой строки результата. Пропускная способность — число запросов, обработанных за выбранный период.
Эти метрики описывают разные проблемы. Отчёт может долго не показывать первую строку, хотя сервер обрабатывает обычное число запросов. При другой нагрузке отдельные операции отвечают быстро, но очередь пользователей снижает общую пропускную способность.
Выберите контрольный сценарий из реальной работы 1С. Подойдёт проведение типового документа, запуск отчёта или открытие журнала за постоянный период. Запишите:
- точное действие пользователя;
- базу и рабочее место;
- начало замера;
- время до первого результата;
- число одновременных пользователей;
- состояние процессора и дисков;
- план запроса, если задержку создаёт SQL Server.
Не смешивайте разные сценарии. Отчёт за месяц и отчёт за год дадут разные результаты даже при одинаковых настройках сервера.
Замеряйте рабочую нагрузку, а не одиночный запуск в пустой базе. Microsoft Learn рекомендует сохранять периодические снимки текущей производительности и собирать историю. Иначе разовый пик попадёт в базовую точку и исказит сравнение.
Соберите исходное состояние четырьмя инструментами
Одного графика загрузки процессора мало. Он покажет занятость ресурса, но не назовёт запрос, который её создал.
Для базовой точки нужны история запросов, текущее состояние SQL Server и показатели операционной системы. Инструменты дополняют друг друга.
| Что наблюдать | Инструмент | Что вы получите |
|---|---|---|
| Историю запросов, планов и статистики выполнения | Query Store | Связь между запросом, его планом и изменением времени выполнения |
| Текущее состояние SQL Server | DMV | Долгие запросы, сведения об индексах и текущие показатели работы |
| Процессор, ввод-вывод и время выполнения запросов | Windows Performance Monitor | Нагрузку на сервер во время контрольного сценария |
| Выполнение текущего запроса | Live Query Statistics | Наблюдение за запросом, который работает прямо сейчас |
| Блокировки и другие события SQL Server | Extended Events | События, которые совпали по времени с задержкой |
Вывод: до первой правки сохраните снимок обычной нагрузки в Query Store, DMV и Performance Monitor.
Query Store автоматически собирает историю запросов, планов и статистику выполнения. Такое назначение инструмента описывает Microsoft Learn. Проверьте, что история действительно накапливается для нужной базы, а не ограничивается моментом вашей проверки.
Performance Monitor нужен для сопоставления. Руководство SQL DBA School относит к его метрикам загрузку процессора, интенсивность ввода-вывода и время выполнения запросов. Запускайте сбор на тот же период, который попадает в Query Store.
DMV показывают состояние SQL Server в момент обращения. SQL DBA School указывает, что через них находят долгие запросы, недостающие индексы и статистику использования существующих индексов. Снимок DMV без времени и описания нагрузки быстро теряет смысл, поэтому сохраняйте контекст вместе с результатом.
Live Query Statistics пригодится, когда тяжёлый запрос ещё выполняется. Microsoft Learn включает этот инструмент в штатный набор наблюдения SQL Server. Для истории после завершения запроса используйте Query Store.
Отделите тяжёлый запрос от общей нехватки ресурсов
Общий симптом «1С работает медленно» объединяет разные неисправности. Грег Робидо перечисляет среди причин блокировки, взаимные блокировки, ожидание ввода-вывода, плохие планы, статистику и проблемы с индексами. Каждая причина требует своей проверки.
Сначала посмотрите, что происходит с остальной нагрузкой. Если один отчёт задерживается, а типовые операции сохраняют прежнее время отклика, не начинайте с настроек всего экземпляра SQL Server.
Найдите запрос в Query Store и сопоставьте его с контрольным запуском. Проверьте историю планов и статистику выполнения. Затем передайте разработчику запрос, план, время запуска и наблюдаемую задержку.
Для отчёта СКД сначала полезно разделить время SQL и дальнейшую обработку результата. Замена сервера не исправит задержку, которая возникла после получения данных из СУБД.
Другая картина — одновременное увеличение времени многих запросов. В этот же период Performance Monitor может показать рост нагрузки на процессор или ввод-вывод. Тогда проверяйте общие ресурсы, tempdb, память и параметры параллелизма.
Не делайте вывод по одному совпадению. Сохраните несколько снимков под сопоставимой нагрузкой. Microsoft Learn рекомендует собирать показатели во времени именно для отделения устойчивой тенденции от текущего состояния.
Проверяйте общие параметры только после локализации задержки
MAXDOP задаёт степень параллелизма SQL Server. Порог стоимости параллелизма влияет на решение оптимизатора использовать параллельный план. SQL DBA School относит оба параметра к настройкам, которые меняют производительность.
Из этих фактов не следует универсальное значение для сервера 1С. Подходящие настройки зависят от состава запросов, планов и доступных ресурсов. Поэтому чужое число без описания нагрузки не годится как отправная точка.
tempdb тоже нельзя настраивать по одному шаблону. SQL DBA School предупреждает, что эта база может ограничить работу SQL Server под тяжёлой нагрузкой при неподходящем размере. Но сам факт высокой активности tempdb ещё не доказывает, что причина задержки найдена.
Проверяйте участки по наблюдаемому признаку.
| Участок | Наблюдаемый признак | Чем проверить | Допустимое действие |
|---|---|---|---|
| Параллелизм | Задержка совпадает с выполнением запросов по параллельным планам | Query Store, план запроса, DMV | Изменить один параметр параллелизма и повторить контрольный сценарий |
tempdb | Замедление многих запросов совпадает с её высокой нагрузкой | DMV и показатели ввода-вывода | Проверить размещение и размер, затем внести одну правку |
| Память | Одновременно меняется поведение нескольких запросов | Performance Monitor и DMV | Искать связь с общей нагрузкой, не с одним отчётом |
| Дисковый ввод-вывод | Рост задержки совпадает с изменением интенсивности операций | Performance Monitor | Проверить дисковый участок и повторить замер |
| План запроса | Один запрос получил другую статистику выполнения | Query Store | Сравнить планы и передать результат разработчику |
| Индексы | DMV указывают на недостающий индекс или отсутствие пользы от существующего | DMV и план запроса | Оценить изменение на одном запросе, затем проверить остальную нагрузку |
Вывод: меняйте только тот участок, связь которого с задержкой видна в Query Store, DMV или Performance Monitor.
Подробные параметры экземпляра и базы лучше сверять с последовательностью подготовки СУБД к нагрузке 1С. Здесь важен не готовый набор значений, а способ проверить их на вашей базе.
Не принимайте рекомендацию индекса за готовое исправление
DMV и Database Engine Tuning Advisor могут указать на недостающий индекс. SQL DBA School описывает такую возможность для обоих инструментов. Но рекомендация ещё не учитывает весь жизненный цикл нагрузки 1С.
Новый индекс способен ускорить чтение одного запроса и изменить работу других операций. Руководство Дэвида Ярда «SQL Server Performance Tuning: The Complete DBA and Developer Guide» предупреждает о регрессиях после добавления индекса, изменения MAXDOP, очистки кэша планов и обновления статистики.
Перед изменением сохраните текущий план и показатели контрольного сценария. После правки повторите не только медленный отчёт, но и несколько типовых операций записи. Иначе вы увидите ускорение чтения, но пропустите ухудшение проведения документов.
Не объединяйте добавление индекса с изменением MAXDOP. Если результат изменится, вы не узнаете причину.
Меняйте один параметр за цикл
Рабочий цикл состоит из четырёх состояний: исходный замер, одна правка, повторный замер и решение. Методика Дэвида Ярда требует менять по одному параметру, чтобы отделить эффект настройки от колебаний нагрузки.
Сохраните для каждого цикла короткую карточку:
| Поле | Что записать | Зачем |
|---|---|---|
| Контрольный сценарий | Операцию 1С, базу и период данных | Чтобы повторить ту же нагрузку |
| Исходное состояние | Время отклика, пропускную способность, план и нагрузку ресурсов | Чтобы получить базу для сравнения |
| Изменение | Один параметр или один индекс | Чтобы связать результат с конкретной правкой |
| Повторный замер | Те же показатели и тот же сценарий | Чтобы увидеть эффект на сопоставимых данных |
| Побочный эффект | Изменения других типовых запросов | Чтобы не принять локальное ускорение за общий успех |
| Решение | Оставить правку или вернуть прежнее состояние | Чтобы следующий цикл начался с понятной конфигурации |
Вывод: карточка превращает настройку SQL Server в проверяемый эксперимент, а не в перебор параметров.
Повторяйте сценарий при близком числе активных пользователей. Microsoft Learn указывает: рост числа пользователей усиливает конкуренцию за ресурсы, увеличивает время отклика и снижает общую пропускную способность. Сравнение утреннего запуска с закрытием месяца ничего не докажет.
Учитывайте кэш планов. В руководстве Дэвида Ярда первый запуск запроса описан как более медленный из-за подготовки плана. Поэтому отмечайте порядок запусков и не сравнивайте первый запуск до изменения со вторым после него.
Очистка кэша ради «чистого теста» сама меняет условия. Она может вызвать регрессии других запросов. Не соединяйте её с настройкой параллелизма, обновлением статистики или добавлением индекса.
Защитите исходное состояние перед обслуживанием
Изменение параметров мониторинга и просмотр планов не заменяют резервную копию. Перед работами, которые затрагивают индексы, статистику или схему обслуживания, проверьте копирование базы средствами SQL Server.
Готовый порядок настройки есть в материале про резервные копии SQL Server для базы 1С. Важно не только получить файл, но и знать, что регламент выполняется до начала работ.
Резервная копия не отвечает на вопрос о производительности. Она сохраняет возможность вернуться к данным, если обслуживание приведёт к нежелательному результату. Не подменяйте контрольный замер наличием копии — нужны оба.
Когда настройку мониторинга можно считать законченной
Базовая настройка готова, когда вы можете воспроизвести полный цикл без догадок:
- Query Store хранит запросы, планы и статистику выполнения нужной базы.
- Performance Monitor пишет показатели процессора и ввода-вывода за тот же период.
- Для контрольной операции 1С записано исходное время до первого результата.
- После одной правки вы повторили тот же сценарий и сравнили показатели.
- Вы проверили соседние запросы на регрессию и решили, оставлять ли изменение.
Если ускорился один запрос, продолжайте работу с его планом и индексами. Если одновременно задерживается вся нагрузка, вернитесь к ресурсам, tempdb и параметрам параллелизма.
Следующую правку начинайте новым циклом. Не присоединяйте её к предыдущей: иначе базовая точка снова исчезнет.