Profilování dotazů šetrné k šířce pásma pro Azure SQL Database

SQL Server vždy poskytoval možnost zachycovat živé dotazy na ad hoc bázi ve formátu sady řádků, který lze snadno konzumovat – nejprve pomocí starší verze SQL Server Profiler, později prostřednictvím Extended Events v SSMS. Tato schopnost je cenná při ladění výkonu, protože události dotazů zahrnují diskrétní metriky CPU a IO a také parametry za běhu, které jsou klíčové pro řešení problémů s výkonem dotazů, jako je sniffování parametrů. Události dotazu dále obsahují další důležité prvky, jako je název hostitele klienta, název aplikace, přihlašovací jméno, ID procesu Windows atd.

Vždy můžete načíst agregované metriky výkonu pro normalizované dotazy z DMV nebo Query Store, ale obsahují pouze kompilované parametry a žádný z výše uvedených prvků. Ačkoli je to užitečné, není to totéž. Pokud například potřebujete vidět konkrétní kombinaci parametrů použitou v tomto dotazu, který provedl 2 miliardy čtení, nebo najít aplikaci s nejvyšší spotřebou CPU za posledních 24 hodin, máte smůlu.

Azure SQL Database není podporována starším Profilerem a Microsoft zakázal poskytovatele streamování XEvents (sys.fn_MSxe_read_event_stream TVF) z důvodů spolehlivosti, takže nemůžete spustit relaci XE a „sledovat živá data“ pomocí SSMS. Query Performance Insights na Azure Portal jsou podporovány Query Store, takže opět máte pouze normalizované dotazy a agregovaná data o výkonu, nikoli skutečné události dotazů.

Takže jsme na pár let uvízli – jedinou možností pro profilování Azure SQL Database bylo ručně vytvořit trasování XEvents, které zapisuje do kruhové vyrovnávací paměti nebo cíle souboru pomocí Azure Storage, přičemž ani jeden z nich není optimální. Použití kruhové vyrovnávací paměti s dotazy T-SQL může být problematické kvůli limitu 4 MB formátovaného XML, jak jej zde pokrývá Jonathan Kehayias, a cíle souborů vyžadují značné množství přeskakování a dalších nákladů. Oba vyžadují ruční dotazování na data XE, a proto nejsou přesně „živé“ v tradičním slova smyslu.

Zadejte Novinka SQL Server Profiler

Když jsem se dozvěděl o rozšíření SQL Server Profiler pro Azure Data Studio, potěšilo mě, že Microsoft konečně dodal grafické řešení pro živé zachycování dotazů v Azure SQL Database. Bohužel, moje vzrušení mělo krátké trvání z několika důvodů.

Za prvé, obávané „Standardní“ trasování ze staršího Profileru bylo zjevně použito jako model pro relaci ADS Profiler XE pro Azure SQL Database s názvem ADS_Standard_Azure ve výchozím stavu. (Relace XE používané pro plný SQL Server jsou podobné.) Jak jsem před několika lety napsal na blog a stále věřím, že standardní trasování je hlavním důvodem, proč je starší Profiler tak špatně hodnocen. Obsahuje několik zbytečných a nefiltrovatelných událostí, jako je spouštění dávky SQL , přihlaste se a odhlásit se a v důsledku toho nepřidává žádnou skutečnou hodnotu pro ladění výkonu. Navíc díky architektuře synchronního trasování sady řádků, kterou používá starší Profiler, může velký objem událostí ovlivnit výkon na vytížených systémech. Z nějakého důvodu tato věc nezmizí!

Za druhé, používá kruhovou vyrovnávací paměť s maximální velikostí 8 MB nebo 1 000 událostí, podle toho, co nastane dříve. Protože události přihlášení/odhlášení jsou malé, často dosáhnete 1000 událostí dlouho předtím, než dosáhnete limitu 8 MB nebo dokonce limitu 4 MB formátovaného XML. Při mírné kombinaci událostí SQL však bude kruhová vyrovnávací paměť XML při mém testování stále 2 až 3 MB při 1 000 událostech a problém je v tom, že celá tato vyrovnávací paměť je natažena po síti pokaždé, když rozšíření Profiler požádá o obnovení jeho mřížka , což je delší z každé 1 sekundy nebo trvání předchozího hlasování. XML je poté analyzováno na straně klienta rozšířením ADS Profiler, aby se zjistilo, které události jsou nové od posledního hlasování, a nové události jsou přidány do mřížky.

Kruhová vyrovnávací paměť se zaplní téměř okamžitě i na středně vytíženém serveru a výsledným efektem je, že z vaší Azure SQL Database budete rychle stahovat>40 megabitů za sekundu přes síť . To znamená 300 megabajtů za minutu nebo 18 gigabajtů za hodinu!

Síťový zásah z rozšíření ADS Profiler (rozsah 4 minut)

Původně jsem se obával, že by to mohlo vést k velkým výstupním poplatkům na příští vyúčtování Azure, ale při pohledu na naše vlastní předplatná Azure jsme nedokázali potvrdit, že síťový provoz pro Azure SQL DB je zpoplatněn. Mike Wood (b|t) ze SentryOne, MVP Azure, se týdny snažil najít odpověď a nakonec se od Microsoftu dozvěděl, že skutečně není za Azure SQL DB aktuálně zpoplatněn výstup ze sítě, i když se to může kdykoli změnit. Přesto se zdá, že stahování 18 GB dat dotazů za hodinu není zodpovědné a mohlo by to jistě zbrzdit vaši další relaci s plným sledováním Netflixu.

Přestože můžete prostřednictvím uživatelského rozhraní Profiler nastavit filtry, které usnadní kontrolu dat, nesníží to však zásah do sítě, protože fungují na straně klienta.

Aktualizovaná relace XE

Rychlým řešením, jak snížit zátěž sítě ADS Profiler a učinit data mnohem dostupnějšími pro ladění výkonu dotazů, je aktualizovat ADS_Standard_Azure relace XE. Níže je skript, který:

• Smažte nepotřebné události:
  • sqlserver.attention
  • sqlserver.existing_connection
  • sqlserver.login
  • sqlserver.logout
  • sqlserver.sql_batch_starting
• Nastavte práh trvání> 1 sekunda (1000000 mikrosekund) pro zbývající události:
  • sqlserver.rpc_completed
  • sqlserver.sql_batch_completed
• Snižte maximální velikost vyrovnávací paměti vyzvánění z 1000 na 10 událostí
  • Toto by nikdy nefungovalo s původním trasováním, protože 10 událostí bude generováno v milisekundách a kruhová vyrovnávací paměť by se příliš rychle recyklovala, což by způsobilo ztrátu většiny událostí. S 1sekundovým filtrem trvání však bude tok událostí mnohem nižší a 10 událostí by mělo dobře fungovat s 1sekundovým intervalem dotazování, který používá 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

Po použití skriptu k aktualizaci relace XE se požární hadice okamžitě zmenší na pramínek:

Snížený počet požadavků na síť po aktualizaci relace ADS Profiler XE

Ještě lehčí alternativy

SQL Sentry a jeho protějšek SaaS SentryOne Monitor jsou jediná další řešení, o kterých vím, pro zachycování dotazů z Azure SQL Database, a to pomocí inovativního přístupu, který je podstatně lehčí než výše optimalizovaná relace XE pro ADS Profiler. Kromě dalších pokročilých funkcí můžete snadno agregovat podle názvu hostitele klienta, aplikace a přihlášení a automaticky zaznamenávat plány dotazů pro analýzu pomocí integrovaného Průzkumníka plánů.

SentryOne Monitor zobrazující zachycené dotazy a plány z Azure SQL Database

Zavírání

Společnost Microsoft uvedla, že bude pokračovat ve vylepšování rozšíření ADS Profiler, a když tak učiní, doufám, že vyřeší výše uvedené problémy. Problém jsem zaregistroval zde. Mezitím aktualizovaný skript zajistí bezpečnější profilování dotazů pro Azure SQL Database, které bude šetrnější k šířce pásma.