Вы когда-нибудь задавались вопросом, насколько Extended Events влияют на производительность вашей рабочей нагрузки (workload)? Я много писал о Extended Events и был активным сторонником их использования в качестве альтернативы SQL Trace даже дольше, чем я работаю на SQLskills.com. Но хоть Extended Events и дают нам множество преимуществ при сборе данных с минимальными накладными расходами, все же бывают случаи, когда нам не обойтись без дополнительных накладных расходов на наблюдение (observation overheads) даже при использовании Extended Events.
Измерение “накладных расходов на наблюдение” в SQL Trace и Extended Events — SQLPerformance.com
SQL Server 2022 предлагает новое расширение функционала Extended Events, благодаря которому мы теперь можем отслеживать производительность и ряд других метрик публикации событий, которые были включены в сеанс, запущенный на сервере. В SQL Server 2022 в DMV sys.dm_xe_session_events были добавлены четыре новых столбца, которые предоставляют дополнительные сведения о показателях производительности публикации событий запущенного сеанса:
Имя столбца |
Тип данных |
Описание |
event_fire_count |
bigint |
Сколько раз событие запускалось (было опубликовано) с момента запуска сеанса. Не обнуляемый. Применим к SQL Server 2022 (16.x) и более поздним версиям. |
event_fire_average_time |
bigint |
Среднее время публикации события в микросекундах. Не обнуляемый. Применим к SQL Server 2022 (16.x) и более поздним версиям. |
event_fire_min_time |
bigint |
Минимальное время, необходимое для публикации события, в микросекундах. Не обнуляемый. Применим к SQL Server 2022 (16.x) и более поздним версиям. |
event_fire_max_time |
bigint |
Максимальное время, необходимое для публикации события, в микросекундах. Не обнуляемый. Применим к SQL Server 2022 (16.x) и более поздним версиям. |
Новые столбцы, добавленные в sys.dm_xe_session_events в SQL Server 2022.
Два новых столбца, event_fire_count и event_fire_average_time, требуют от вас включения флага трассировки 9708 для сбора данных. Это отражено в следующей электронной документации:
Флаги трассировки (Transact-SQL) — SQL Server | Microsoft Learn
Эти столбцы не будут заполняться, если вы не включите указанный флаг трассировки. Этот флаг трассировки является global only, поэтому его необходимо включать с помощью DBCC TRACEON(9708, -1). Я решил посмотреть на результат следующего запроса сначала без включения флага, а затем с включенным флагом:
SELECT s.name AS session_name,
event_name,
event_fire_count,
event_fire_average_time,
event_fire_min_time,
event_fire_max_time
FROM sys.dm_xe_sessions AS s
INNER JOIN sys.dm_xe_session_events AS xse
ON s.address = xse.event_session_address
ORDER BY event_fire_max_time DESC
![](https://habrastorage.org/getpro/habr/upload_files/6b4/6cb/e8c/6b46cbe8c5481fb82d66c2d73ea94a52.png)
Показатели производительности дефолтных extended events без флага трассировки 9708.
![](https://habrastorage.org/getpro/habr/upload_files/de6/204/68b/de620468bd20b4d43f7fd2cfb0ce716a.png)
Показатели производительности дефолтных extended events с включенным флагом трассировки 9708.
Флаг трассировки является global only, поэтому я включил его с помощью DBCC TRACEON(9708, -1). Хоть эта система не может похвастаться постоянной огромной рабочей нагрузкой, приятно видеть, что общее влияние на производительность дефолтных сеансов довольно низкое.
Однако я был настроен на эксперименты и хотел сделать что-то невероятно глупое с этим флагом трассировки, поэтому я создал на том же сервере сеанс под именем CrazyEvents, выполнил SELECT ALL в пользовательском интерфейсе, добавил в сеанс каждый недебажный канала событий и запустил его. Я не буду демонстрировать в этом блогпосте скрипт, который я использовал, чтобы сделать это, ведь в первую очередь это глупая идея, и вы сами легко можете воспроизвести этот сеанс в пользовательском интерфейсе, если захотите присоединиться ко мне в психушке. Вам придется подождать от нескольких секунд до минут, пока такое количество событий будут добавлены к сеансу. Я должен ответить, что редактирования определения этого сеанса чуть позже в SSMS было достаточно, чтобы запустить кулеры моего ноутбука.
Для относительно стабилизированной системы, где выполнялись лишь запросы, связанные с этим блогпоста, результаты меня немного удивили. Я не ожидал, что 4.5 мс времени запуска для события wait_info выплывет как самое продолжительное событие по запуску из относительно стабилизированной системы.
![](https://habrastorage.org/getpro/habr/upload_files/e18/fda/74a/e18fda74af55e01437f684d2d211144a.png)
Показатели производительности запуска extended event сеанса CrazyEvents
Хоть мне пока непонятно, стоит ли включать флаг трассировки для двух дополнительных столбцов, я очень рад, что Microsoft продолжает вкладывать средства в усовершенствования Extended Events, которые позволяют лучше диагностировать влияние на производительность вызванные определенными сеансами и собираемыми событиями. До добавления этих усовершенствований не существовало точных способов определения того, оказывает ли событие негативное влияние на производительность и, если да, то в какой степени, кроме банального наблюдения за поведением с запущенным сеансом события и без него. Теперь в нашем арсенале есть полноценное средство определения для оценки влияет событие на производительность.
Иногда так сложно разобраться, какие есть варианты переноса данных между разными серверами БД, какой способ выбрать и в чем разница. Приглашаем всех желающих на открытый урок, на котором поговорим о том, какие возможности есть в MS SQL server, в чем их различия и для каких задач каждый способ подходит лучше.
Урок состоится в рамках онлайн-курса "MS SQL Server Developer". Успевайте зарегистрироваться — урок пройдет уже сегодня вечером.