Dopad události query_post_execution_showplan Extended v SQL Server 2012

Jednou z nejnáročnějších výzev na serveru SQL Server je odstraňování problémů s citlivostí parametrů nebo odhadem mohutnosti, které způsobují snížení výkonu pracovní zátěže. Obecně budete muset mít spuštěný skutečný plán provádění z příkazu, abyste mohli určit příčinu snížení výkonu. V SQL Server 2012 poskytuje rozšířená událost query_post_execution_showplan možnost zachytit skutečný plán provádění příkazů. Jakkoli se to zdá užitečné, tato událost není něčím, co lze použít bez výrazného dopadu na výkon na pracovní zátěž běžící na serveru.

Ve svém článku Měření „Observer Overhead“ trasování SQL vs. Extended Events jsem ukázal srovnání dopadu trasování SQL na výkon s identickou konfigurací pomocí Extended Events v SQL Server 2012.  V době, kdy jsem původně testoval tento článek Také jsem hodně testoval událost query_post_execution_showplan v SQL Server 2012.  Tato událost byla poprvé představena v SQL Server 2012 CTP1, kdy bylo mnoho událostí trasování přeneseno do Extended Events, aby byla zajištěna parita s SQL Trace. V té době měla událost pouze podmnožinu sloupců, které byly zahrnuty do konečného RTM serveru SQL Server 2012.

Během CTP1 jsem odeslal položku Connect s požadavkem, aby byla vytvořena akce, která umožní shromažďování skutečného plánu provádění s událostmi v SQL Server 2012.  Cílem bylo být schopni použít události module_end nebo sql_statement_completed k identifikaci, kdy se provádí procedura. nebo prohlášení překračuje svou běžnou dobu trvání. Například ve scénáři citlivosti parametrů, kde je pro normální hodnoty parametrů generován méně ideální plán, lze událost použít ke shromáždění skutečného plánu provádění pro daný příkaz prostřednictvím akce. V reakci na to přidal tým SQL Serveru do události query_post_execution_showplan sloupce trvání a cpu_time, aby definice predikátu mohly shromažďovat pouze tuto událost pro tyto scénáře.

Bohužel to nemá stejné výhody, jaké by měla implementace jako akce na výkon. Ve zbytku tohoto příspěvku vysvětlím proč.

Dopad na výkon

V době, kdy jsem testoval svůj předchozí článek, jsem také testoval režii spojenou s událostí query_post_execution_showplan, především proto, že mě opravdu zajímalo její použití v několika klientských produkčních systémech, a než jsem to udělal, potřeboval jsem pochopit, co jaký dopad by událost měla na jejich pracovní vytížení. Byl jsem opravdu zděšen výsledky, které jsem získal ze svých původních testů, a poté, co jsem nechal Aaron Bertrand ověřit mé výsledky pomocí interního testovacího svazku SQL Sentry, zadal jsem další položku Connect, která hlásila problémy s výkonem, která byla následně uzavřena jako „By Design“ .

Pro testování dopadu na výkon byla použita přesně stejná pracovní zátěž a konfigurace distribuovaného přehrávání z článku Měření „Observer Overhead“ v článku SQL Trace vs. Extended Events. Jediný rozdíl ve výsledcích testů uvedených v tomto článku spočívá v tom, že pro prostředí VM byl použit novější, výkonnější hostitelský systém. Použité virtuální počítače byly naprosto stejné, beze změn v jejich konfiguraci, a byly jednoduše zkopírovány do nového systému, což je důvod, proč základní pracovní zátěž dokázala provést přehrávání rychleji s vyšším průměrem dávkových požadavků/s. Základní výsledky byly zachyceny pomocí standardní instalace SQL Server 2012, přičemž na serveru byla spuštěna pouze výchozí relace události system_health.

Pro srovnání dopadu na výkon query_post_execution_showplan událost, byla použita následující definice relace události.

CREATE EVENT SESSION [query_post_execution_showplan Overhead]
ON SERVER
ADD EVENT sqlserver.query_post_execution_showplan(
WHERE ([duration]=(5000000)));
GO

Tato relace ve skutečnosti neshromažďuje data události pomocí cíle a používá predikát doby trvání události, která se rovná 5000000 mikrosekundám nebo pěti sekundám trvání. Pro pracovní vytížení přehrávání nemá žádný spouštěný příkaz trvání přesně pět sekund, takže událost query_post_execution_showplan se na serveru ve skutečnosti nikdy nespustí a jakékoli snížení výkonu je výhradně výsledkem sběru dat události a následného vyhodnocení predikátu. Výsledky testů jsou uvedeny v tabulce 1 a v grafu 2.

Tabulka 1 – režie události query_post_execution

Graf 2 – režie události query_post_execution

V tomto kole testů se výkon zátěže sníží zhruba o 30 % tím, že tuto událost jednoduše povolíte v relaci události, i když se nespustí pro žádnou z událostí, které se na serveru přehrávají. Celková degradace bude záviset na skutečné zátěži serveru a je důležité poznamenat, že tato série testů odráží spíše scénář nejhoršího případu, protože Distributed Replay bylo spuštěno v zátěžovém režimu a využití CPU na serveru SQL bylo fixováno. na 94 % v průměru během testů.

Pochopení dopadu na výkon

Důvod, proč tato událost představuje tak významnou režii na výkon, lze vysvětlit z životního cyklu události v Rozšířených událostech. Když je během provádění zjištěn kritický bod v kódu SQL Server přidružený k události, kód provede velmi rychlou booleovskou kontrolu, aby zjistil, zda je událost povolena v jakékoli relaci aktivní události na serveru. Pokud je událost povolena pro relaci aktivní události, shromažďují se všechny datové sloupce přidružené k události, včetně všech přizpůsobitelných sloupců, které byly zapnuty. V tomto okamžiku událost vyhodnotí všechny predikáty pro aktivní relace události, které událost shromažďují, aby určila, zda se událost skutečně úplně spustí.

U události query_post_exection_showplan má veškerý dopad na výkon režie spojená se shromažďováním dat. I v případě, že existuje predikát pro trvání rovnající se pěti sekundám, pouhým zapnutím události v relaci události musí shromáždit Showplan XML pro každý příkaz, který se provede na serveru, aby bylo možné predikát vyhodnotit. a pak určit, že událost nespustí. Z tohoto důvodu je třeba se vyhnout události query_post_execution_showplan pro produkční úlohy. Pro pracovní zátěž testovacího přehrání musela být událost vyhodnocena zhruba 440 000krát, i když se ve skutečnosti nespustí pro pracovní zátěž a testovanou relaci události, protože žádná z událostí přehrání netrvá přesně pět sekund. Informace o počtu událostí byly shromážděny přidáním cíle event_counter do relace události a odstraněním predikátu trvání a poté znovu otestováním zátěže přehrávání s následující definicí relace.

CREATE EVENT SESSION [query_post_execution_showplan Overhead] 
ON SERVER
ADD EVENT sqlserver.query_post_execution_showplan
ADD TARGET package0.event_counter;
GO

Porovnání s rychle se spouštějícími událostmi

Abychom poskytli referenční rámec pro tento dopad na výkon, můžeme se podívat na režii zapnutí sady často spouštěných událostí na serveru a provádění stejné pracovní zátěže přehrávání. Dvě z nejčastěji spouštěných událostí na serveru SQL jsou události lock_acquired a lock_released. K porovnání režie těchto dvou událostí lze použít následující relace události, která shromažďuje události bez predikátu, takže se shromažďuje každé provedení a počítá, jak často se spouští pomocí cíle event_counter.

CREATE EVENT SESSION [locking Overhead] 
ON SERVER
ADD EVENT sqlserver.lock_acquired,
ADD EVENT sqlserver.lock_released
ADD TARGET package0.event_counter;
GO

Při našem pracovním vytížení při přehrávání se tyto dvě události spustí zhruba 111 180 000krát. Režii související se shromažďováním těchto událostí lze vidět v tabulce 3 a grafu 4.

Tabulka 3 – Zamykání režijního srovnání

Graf 4 – Porovnání režie zamykání událostí

Jak můžete vidět z údajů, účinek těchto událostí na výkon je výrazně nižší než u query_post_execution_showplan, i když byla definice relace události uzamčení nakonfigurována tak, aby umožňovala spouštění všech událostí na serveru, celková režie byla celkově pod 1 %. . Mějte na paměti, že relace události zamykání vyhodnotila ekvivalent 500krát více událostí a v tomto případě se všechny události ve skutečnosti musely spustit pro relaci události, kde se událost query_post_execution_showplan ve skutečnosti po vyhodnocení spustit nemusela.

Shrnutí

Zatímco událost query_post_execution_showplan poskytuje možnost shromáždit skutečný plán dotazů pro příkaz, který se provede, dopad na výkon sběru dat pouze za účelem vyhodnocení události z ní dělá něco, co není životaschopné pro produkční použití. Minimálně byste měli zvážit režii předtím, než tuto událost použijete proti produkčnímu zatížení. Dokonce i popis události poskytnutý společností Microsoft uznává, že událost může mít významný dopad na výkon (zdůrazňuji):

Popis události lze nalézt ve sloupci popisu v zobrazení katalogu sys.dm_xe_objects nebo v uživatelském rozhraní New Session, jak je znázorněno na obrázku 5 (moje zvýraznění):

Obrázek 5 – Popis události z uživatelského rozhraní nové relace

Před skutečným použitím v produkčním prostředí bych doporučil provést benchmarking výkonu jakékoli události s tímto varováním v popisu.