Оптимизация производительности информационных систем на базе платформы 1С:Предприятие часто упирается в необходимость глубокого анализа работы с базой данных. Когда стандартные средства мониторинга, такие как журнал регистрации или технологический журнал (ТЖ), не дают полной картины происходящего на уровне СУБД, администраторы и разработчики обращаются к специализированным утилитам. Одним из таких мощных инструментов является SQL Profiler, входящий в состав Microsoft SQL Server.
Этот инструмент позволяет перехватывать и анализировать события, происходящие в движке базы данных в реальном времени. Грамотная настройка трассировки помогает выявить"узкие места" в коде конфигурации, найти блокировки транзакций и определить запросы, потребляющие избыточные ресурсы сервера. Однако неправильное использование профилировщика может, парадоксальным образом, еще больше замедлить работу системы из-за накладных расходов на сбор данных.
В данной статье мы подробно разберем процесс инициализации сессии профилирования, выбор корректных шаблонов событий и применение фильтров для изоляции проблемных запросов именно от платформы 1С. Вы узнаете, как интерпретировать полученные данные и какие параметры являются наиболее критичными для настройки высоконагруженных систем.
Подключение к серверу и выбор шаблона трассировки
Запуск утилиты осуществляется через меню Tools в среде SQL Server Management Studio (SSMS). После выбора пункта SQL Server Profiler откроется окно подключения к экземпляру сервера. Здесь необходимо указать имя сервера и выбрать метод аутентификации. Для корректной работы требуется учетная запись с правами на выполнение трассировки, обычно это роль sysadmin или специально выданные права ALTER TRACE.
После успешного подключения откроется окно New Trace, где первым делом необходимо выбрать шаблон (Template). Для задач, связанных с 1С, стандартный шаблон TSQL_Replay или Standard часто оказывается избыточным или, наоборот, недостаточным. Оптимальным выбором для первичного анализа является шаблон TSQL_Locks или создание собственного пустого шаблона, в который вы вручную добавите только необходимые события. Это снижает нагрузку на сервер во время сбора данных.
Обратите внимание на чекбокс Enable file rollover. Если вы планируете длительную сессию записи, активация этой опции позволит создавать новые файлы логов по достижении определенного размера, предотвращая переполнение диска одним гигантским файлом трассировки. Также рекомендуется сразу установить ограничение на максимальный размер файла, чтобы избежать аварийной остановки сервера из-за нехватки дискового пространства.
- 🔍 Используйте минимально необходимый набор событий для снижения оверхеда на сервере.
- 💾 Всегда ограничивайте размер файла трассировки или включайте циклическую перезапись.
- 🔐 Убедитесь, что ваша учетная запись имеет привилегию
ALTER TRACEна уровне сервера.
Настройка фильтров событий для изоляции 1С
Самым важным этапом настройки является фильтрация событий. База данных 1С может обслуживать множество клиентов, и нам нужно отсечь весь посторонний шум, оставив только запросы от платформы. Для этого перейдите на вкладку Filters в окне свойств трассировки. В дереве фильтров найдите параметр DatabaseName и укажите имя вашей информационной базы. Это сузит круг наблюдаемых событий до конкретной базы данных.
Далее необходимо отфильтровать приложения. Платформа 1С идентифицирует себя в заголовке соединения. В параметре ApplicationName добавьте фильтр, содержащий строку 1C:Enterprise или 1S:Enterprise (в зависимости от локали сервера). Это действие исключит из выборки запросы от других программ, работающих с этим экземпляром SQL Server, таких как сторонние отчеты или административные скрипты.
Для более глубокого анализа можно использовать фильтр по LoginName, если в базе данных созданы отдельные пользователи SQL для разных информационных баз или сервисных задач. Однако в типовой конфигурации 1С часто используется один системный пользователь, поэтому фильтрация по имени приложения является более надежным методом. Не забудьте также установить фильтр по длительности выполнения (Duration), чтобы сразу отсекать мгновенные запросы, которые не представляют интереса для оптимизации.
⚠️ Внимание: Фильтрация по тексту запроса (
TextData) с использованием оператора"Like" значительно увеличивает нагрузку на сервер трассировки. Используйте этот метод только в крайних случаях, когда другие фильтры не помогают локализовать проблему.
Для поиска конкретных медленных запросов установите фильтр Duration больше 1000 (мс). Это позволит игнорировать быстрые служебные запросы и сфокусироваться на реальных тормозах.
Выбор ключевых событий для мониторинга
Вкладка Events Selection позволяет выбрать конкретные классы событий, которые будут записываться в лог. Для диагностики проблем производительности 1С критически важны события из категории Stored Procedures и TSQL. Основное событие, которое нас интересует — RPC:Completed. Именно через него платформа 1С выполняет большинство хранимых процедур и подготовленных запросов к базе данных.
Также полезно добавить событие SQL:BatchCompleted, которое фиксирует завершение выполнения пакетов SQL-запросов. В сочетании с SP:StmtCompleted это позволяет увидеть детализацию выполнения внутри хранимых процедур. Однако включение всех подряд событий приведет к генерации огромного объема данных, который будет сложно анализировать. Сосредоточьтесь на событиях завершения (Completed), так как они содержат информацию о времени выполнения и количестве прочитанных строк.
Не забудьте включить события, связанные с блокировками, если вы подозреваете проблемы с конкурентным доступом к данным. События из категории Locks, такие как Lock:Deadlock или Lock:Timeout, помогут выявить ситуации, когда пользователи ждут освобождения ресурсов. Для анализа транзакций полезно отслеживать SQLTransaction, чтобы понимать длительность открытых транзакций, что часто является причиной роста журнала транзакций.
| Событие (Event) | Категория | Зачем нужно в 1С |
|---|---|---|
RPC:Completed |
Stored Procedures | Основной вызов запросов от платформы 1С |
SQL:BatchCompleted |
TSQL | Выполнение пакетов SQL (реже используется в 1С) |
Lock:Deadlock |
Locks | Фиксация взаимных блокировок (взаимоблокировок) |
SP:StmtCompleted |
Stored Procedures | Детализация выполнения внутри хранимой процедуры |
Attention |
General | Прерывание запроса клиентом (например, нажатие"Отмена") |
Интерпретация колонок данных трассировки
После запуска трассировки вы увидите поток событий в сетке данных. Чтобы анализ был эффективным, необходимо настроить отображаемые колонки через меню Columns. Самая важная колонка — Duration. Она показывает время выполнения запроса в микросекундах. Для удобства анализа можно отсортировать таблицу по убыванию этого значения, чтобы сразу увидеть самые тяжелые запросы.
Колонка TextData содержит текст самого запроса или имя хранимой процедуры. В случае с 1С здесь часто отображаются вызовы процедур вида dbo._xxxxx. Для понимания логики работы может потребоваться декодирование этих имен или анализ параметров, передаваемых в процедуру. Колонка Reads показывает количество логических чтений страниц из памяти, что является отличным индикатором эффективности индексов.
Если значение Reads аномально высокое при малом количестве возвращаемых строк (RowCount), это верный признак отсутствия подходящего индекса или его неоптимального использования. Также обратите внимание на колонку CPU, которая отражает процессорное время, затраченное на выполнение запроса. Высокое значение CPU при низком Duration может указывать на сложные вычисления внутри запроса.
Почему Duration может быть большим, а CPU маленьким?
Это классический признак проблем с вводом-выводом (I/O). Запрос долго ждал чтения данных с диска или освобождения блокировок, но само процессорное время обработки было минимальным. Ищите проблемы с дисковой подсистемой или блокировками.
Анализ планов выполнения и оптимизация
Сам по себе SQL Profiler лишь собирает данные. Для глубокого анализа конкретного тяжелого запроса, найденного в трассировке, необходимо получить его план выполнения. Вы можете скопировать текст запроса из колонки TextData и выполнить его в окне запроса SSMS с включенной опцией Include Actual Execution Plan (или нажать Ctrl+M).
Анализ плана выполнения покажет, какие операторы потребляют больше всего ресурсов. Обратите внимание на операции Table Scan или Clustered Index Scan, которые свидетельствуют о полном переборе таблиц. В идеале для выборки данных должны использоваться операции Index Seek. Если вы видите предупреждения об отсутствии статистики или несоответствии типов данных, это прямое указание на необходимость обновления статистики или исправления кода запроса.
Для сложных случаев, когда запрос формируется динамически внутри конфигурации 1С, может потребоваться использование расширенных событий (Extended Events) вместо классического Profiler, так как они менее ресурсоемки. Однако для разовых акций по поиску"тормозов" классический профилировщик остается наиболее наглядным и привычным инструментом для большинства специалистов.
⚠️ Внимание: Никогда не оставляйте трассировку SQL Profiler включенной на продуктивном сервере в фоновом режиме на длительное время. Это создает значительную нагрузку и может привести к деградации производительности всей системы 1С.
☑️ Чек-лист перед запуском трассировки
Сохранение и экспорт результатов анализа
После завершения сбора данных трассировку необходимо сохранить для последующего детального изучения или передачи разработчикам. Используйте меню File -> Save As -> Trace File. Формат .trc является нативным для SQL Profiler и позволяет повторно открыть файл в утилите для сортировки и фильтрации уже постфактум, без нагрузки на сервер баз данных.
Если требуется передать данные коллеге, у которого нет доступа к серверу, или подготовить отчет, можно экспортировать данные в формат SQL Script (File -> Export -> Extract SQL Server Trace Data). Это позволит воссоздать события на тестовом сервере. Также доступна выгрузка в таблицы базы данных, что удобно для построения сводных отчетов средствами самого SQL.
При анализе сохраненных файлов используйте функцию группировки (Group By). Например, сгруппировав события по колонке TextData или ObjectName, вы сможете быстро выявить типичные повторяющиеся запросы, которые суммарно потребляют больше всего ресурсов, даже если их выполнение не выглядит критичным.
Главная цель использования SQL Profiler в 1С — не постоянный мониторинг, а точечная диагностика конкретных эпизодов замедления работы системы для последующей оптимизации кода или индексов.
Можно ли использовать SQL Profiler на сервере 1С в рабочее время?
Кратковременное использование (5-15 минут) с жесткими фильтрами допустимо, но это всегда риск. Лучше проводить диагностику в нерабочее время или на копии базы. Классический Profiler создает заметную нагрузку, в отличие от Extended Events.
Что делать, если в TextData видны только имена хранимых процедур?
Платформа 1С часто использует подготовленные запросы. Чтобы увидеть параметры, передаваемые в процедуру, нужно добавить в события колонку BinaryData или использовать более глубокий уровень трассировки, однако это усложняет чтение лога.
Чем отличается RPC:Completed от SQL:BatchCompleted в контексте 1С?
1С преимущественно использует удаленные вызовы процедур (RPC) для выполнения запросов к СУБД. Событие RPC:Completed является основным источником информации о запросах 1С. SQL:BatchCompleted встречается реже, обычно при выполнении служебных скриптов или прямых запросов.
Как найти запрос, который вызвал взаимоблокировку (Deadlock)?
В SQL Profiler нужно отфильтровать событие Lock:Deadlock или Lock:Deadlock Chain. В тексте события (TextData) будет содержаться XML-описание графа блокировок, где указаны жертва deadlock и процессы, которые его вызвали.
Нужно ли обновлять статистику перед запуском профилировщика?
Желательно. Актуальная статистика гарантирует, что планы выполнения запросов во время трассировки будут соответствовать реальным рабочим условиям. Устаревшая статистика может привести к неоптимальным планам, которые искажут картину производительности.