Удобно за честотната лента профилиране на заявки за Azure SQL база данни

SQL Server винаги е предоставял възможността за улавяне на заявки на живо на ad hoc база в лесно използваем формат на набор от редове – първо с наследен SQL Server Profiler, по-късно чрез разширени събития в SSMS. Тази способност е ценна при настройка на производителността, тъй като събитията на заявката включват дискретни CPU и IO метрики, както и параметри по време на изпълнение, които са ключови за отстраняване на проблеми с производителността на заявката, като например подслушване на параметри. Освен това събитията на заявка съдържат други важни елементи като име на хост на клиента, име на приложение, вход, идентификационен номер на процес в Windows и т.н.

Винаги можете да извлечете обобщени показатели за ефективност за нормализирани заявки от DMV или Query Store, но те съдържат само компилирани параметри и нито един от гореспоменатите елементи. Въпреки че това е полезно, не е същото. Например, ако трябва да видите конкретната комбинация от параметри, използвана от тази заявка, която е направила 2 милиарда четения, или да намерите приложението, което най-много консумира CPU през последните 24 часа, нямате късмет.

Azure SQL Database не се поддържа от наследения Profiler и Microsoft деактивира доставчика на поточно предаване на XEvents (sys.fn_MSxe_read_event_stream TVF) от съображения за надеждност, така че не можете да завъртите XE сесия и да „гледате данни на живо“ с SSMS. Статистиката за ефективността на заявките в портала Azure се поддържа от Query Store, така че отново имате само нормализирани заявки и обобщени данни за ефективността, а не действителните събития на заявка.

И така, в продължение на няколко години бяхме блокирани – единствената опция за профилиране на Azure SQL база данни беше ръчно създаване на XEvents трасиране, което записва в пръстен буфер или целеви файл с Azure Storage, нито едно от които не е оптимално. Използването на пръстен буфер с T-SQL заявки може да бъде проблематично поради ограничението от 4MB форматиран XML, както е обхванато от Джонатан Кехайяс тук, а целевите файлове изискват доста прескачане на обръч и допълнителни разходи. И двете изискват ръчно запитване на XE данните и затова не са точно „на живо“ в традиционния смисъл.

Въведете Ново SQL Server Profiler

Когато научих за разширението на SQL Server Profiler за Azure Data Studio, бях доволен да видя, че Microsoft най-накрая предостави графично решение за улавяне на заявки на живо в Azure SQL база данни. За съжаление, вълнението ми беше краткотрайно по няколко причини.

Първо, страшната „стандартна“ следа от наследения Profiler очевидно е била използвана като модел за сесията ADS Profiler XE за Azure SQL база данни , наречен ADS_Standard_Azure по подразбиране. (XE сесиите, използвани за пълен SQL Server, са подобни.) Както писах в блог преди няколко години и все още вярвам, че стандартното проследяване е основната причина, поради която наследеният Profiler е толкова лошо разглеждан. Той съдържа множество безполезни и нефилтриращи събития, като Стартиране на SQL пакет , влезте и изход , и в резултат на това не добавя реална стойност за настройка на производителността. Освен това, със синхронната архитектура за проследяване на набор от редове, използвана от наследения Profiler, големият обем на събитията може да повлияе на производителността на натоварени системи. По някаква причина това нещо няма да изчезне!


*Стандартни събития за проследяване на наследени профили*	ADS Profiler „ADS_Standard_Azure“ XE събития – изглеждате ли познати?

Второ, той използва пръстен буфер с максимален размер от 8MB или 1000 събития, което от двете настъпи първо. Тъй като събитията за влизане/излизане са малки, често ще достигате 1000 събития много преди да достигнете ограничението от 8MB или дори ограничението от 4MB форматиран XML. Въпреки това, с умерена комбинация от SQL събития, XML буферът на пръстена все още ще бъде 2 до 3MB при 1000 събития в моето тестване и проблемът е, че целият този буфер се изтегля в мрежата всеки път, когато разширението Profiler запитва за опресняване неговата решетката , което е по-дългият от всяка 1 секунда или продължителността на предишната анкета. След това XML се анализира от страна на клиента от разширението на ADS Profiler, за да се определи кои събития са нови след последната анкета и новите събития се добавят към мрежата.

Буферът на пръстена се запълва почти мигновено дори и на умерено натоварен сървър и чистият ефект е, че бързо ще изтегляте>40 мегабита в секунда в мрежата от вашата Azure SQL база данни . Това означава 300 мегабайта в минута или 18 гигабайта на час!

Посещение в мрежата от разширението на ADS Profiler (4-минутен диапазон)

Първоначалният ми страх беше, че това може да доведе до огромни изходни такси при следващата сметка за Azure, но гледайки нашите собствени абонаменти за Azure, не успяхме да потвърдим, че мрежовият трафик за Azure SQL DB се таксува. Майк Ууд (b|t) от SentryOne, Azure MVP, прекара седмици в опити да намери отговора и най-накрая получи съобщение от Microsoft, че наистина изходът към мрежата в момента не се таксува за Azure SQL DB, въпреки че това може да се промени по всяко време. Въпреки това изтеглянето на 18 GB данни за заявки на час не изглежда отговорно и със сигурност може да попречи на следващата ви сесия за гледане в Netflix.

Въпреки че можете да зададете филтри през потребителския интерфейс на Profiler, което ще улесни прегледа на данните, това няма да намали мрежовото въздействие, тъй като те работят от страна на клиента.

Актуализирана XE сесия

Бързо решение за намаляване на мрежовата тежест на ADS Profiler и за превръщане на данните в много по-консумативни за настройка на производителността на заявките е да актуализирате ADS_Standard_Azure XE сесия. По-долу е даден скрипт, който ще:

Изтрийте безполезните събития:
- sqlserver.attention
- sqlserver.existing_connection
- sqlserver.login
- sqlserver.logout
- sqlserver.sql_batch_starting
Задайте праг на продължителност> 1 секунда (1000000 микросекунди) за останалите събития:
- sqlserver.rpc_completed
- sqlserver.sql_batch_completed
Намалете максималния размер на буфера на пръстена от 1000 на 10 събития
- Това никога няма да работи с оригиналното проследяване, тъй като 10 събития ще бъдат генерирани за милисекунди и буферът на пръстена ще се рециклира твърде бързо, което води до загуба на повечето събития. Въпреки това, с филтъра за продължителност от 1 секунда потокът на събитията ще бъде много по-нисък и 10 събития трябва да работят добре с 1-секундния интервал на запитване, използван от ADS Profiler.

ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE 
DROP EVENT sqlserver.attention,
DROP EVENT sqlserver.existing_connection,
DROP EVENT sqlserver.login,
DROP EVENT sqlserver.logout,
DROP EVENT sqlserver.rpc_completed,
DROP EVENT sqlserver.sql_batch_completed,
DROP EVENT sqlserver.sql_batch_starting
GO
 
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE 
ADD EVENT sqlserver.rpc_completed(
ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.client_pid,sqlserver.database_id,sqlserver.query_hash,sqlserver.session_id,sqlserver.username)
      WHERE (([package0].[equal_boolean]([sqlserver].[is_system],(0))) AND ([duration] >= (1000000)))),
ADD EVENT sqlserver.sql_batch_completed(
ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.client_pid,sqlserver.database_id,sqlserver.query_hash,sqlserver.session_id,sqlserver.username)
      WHERE (([package0].[equal_boolean]([sqlserver].[is_system],(0))) AND ([duration] >= (1000000))))
GO
 
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE 
DROP TARGET package0.ring_buffer
GO
 
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE 
ADD TARGET package0.ring_buffer(SET max_events_limit=(10),max_memory=(51200))
GO

След прилагане на скрипта за актуализиране на XE сесията, пожарният маркуч ще бъде незабавно намален до струйка:

Намалено попадане в мрежата след актуализиране на сесията ADS Profiler XE

Още по-леки алтернативи

SQL Sentry и неговият SaaS аналог SentryOne Monitor са единствените други решения, които познавам за улавяне на заявки от Azure SQL база данни и те правят това, използвайки иновативен подход, който е значително по-лек от горната оптимизирана XE сесия за ADS Profiler. Наред с други разширени функции, можете лесно да агрегирате по име на хост на клиента, приложение и вход и автоматично да улавяте планове на заявки за анализ с интегрирания Plan Explorer.

SentryOne Monitor, показващ заснети заявки и планове от Azure SQL база данни

Затваряне

Microsoft заяви, че ще продължат да подобряват разширението ADS Profiler и когато го направят, се надявам, че ще се справят с проблемите, описани по-горе. Регистрирах проблема тук. Междувременно актуализираният скрипт ще осигури по-безопасно и по-удобно за честотната лента опит за профилиране на заявки за Azure SQL база данни.