Moje kolegyně Erin Stellato se mě nedávno zeptala na otázku, kde a proč by mohlo dojít ke ztrátě událostí s Extended Events. Tato otázka byla výsledkem komentáře, který někdo napsal k jednomu z jejích blogových příspěvků, který tvrdil, že showplan_xml události nelze shromažďovat XE Profiler nebo prostřednictvím „živého“ streamu událostí ze serveru. Náhodou vím, že to není správné, protože jsem rutinně demonstroval negativní dopady na výkon používání události post_query_execution_showplan proti produkčnímu vytížení přidáním události do uživatelského rozhraní a tím, že jsem nechal sledovat živá data, takže to zahájilo hlubší diskusi. o tom, jak a kdy Extended Events zruší událost, která byla vygenerována během sběru dat.
Na velikosti události záleží
Rozšířené události konfigurují vnitřní vyrovnávací paměť pro relaci události při jejím počátečním spuštění na serveru a konfigurace voleb relace události určuje, jak velké jsou vyrovnávací paměti a maximální velikost události, kterou může relace události shromáždit. Zatímco většina událostí generovaných Extended Events je relativně lehká a malá v binárním formátu, konkrétní události mohou generovat mnohem větší užitečné zatížení dat, která musí být ukládána do vyrovnávací paměti. Výchozí možnosti relace události vedou ke konfiguraci relace se třemi vnitřními vyrovnávací paměti pro uložení událostí o velikosti 1 441 587 bajtů. Velikost a počet vyrovnávacích pamětí pro relaci události lze nalézt v sys.dm_xe_sessions DMV, zatímco relace STATE=START na serveru:
SELECT s.name, s.total_regular_buffers, s.regular_buffer_size, s.total_large_buffers, s.large_buffer_size, s.total_buffer_sizeFROM sys.dm_xe_sessions AS s;
Všimněte si, že pro každou systémově definovanou relaci událostí je nula velkých vyrovnávacích pamětí a velikost velké vyrovnávací paměti je také nastavena na nulu, což je výchozí konfigurace. Velké vyrovnávací paměti pro relaci události se vytvoří pouze tehdy, když je pro relaci události nakonfigurována možnost relace MAX_EVENT_SIZE. Výchozí hodnota pro tuto volbu je 0, což znamená, že největší událost, kterou může relace události skutečně spotřebovat, je velikost běžné vyrovnávací paměti, což je 1 441 587 bajtů. Pro určité události, jako jsou ty, které vytvářejí showplan_xml, je ve skutečnosti relativně snadné mít velikost události, která je větší než výchozí velikost vyrovnávací paměti pro relaci události. V těchto případech by velká událost byla relací události ve skutečnosti zahozena, protože ji nelze umístit do vyrovnávací paměti pro odeslání.
Kontrola ztráty událostí
Existují tři specifické možnosti relace, které určují, jak velkou událost může relace události skutečně shromáždit, a jedna, která řídí, jak jsou události zrušeny, když je vyrovnávací paměť pro relaci události plná nebo pod tlakem. Všechny tyto čtyři jsou důležité, když mluvíme o shromažďování událostí, které by mohly generovat velké užitečné zatížení události, a chceme minimalizovat šanci, že bychom mohli událost potenciálně zahodit. Příklad relace události, která by byla náchylná ke ztrátě události kvůli tlaku paměti ve vyrovnávací paměti pro relaci události, je níže:
VYTVOŘIT RELACI UDÁLOSTI [Zámky] NA SERVERU PŘIDAT UDÁLOST sqlserver.lock_acquired,PŘIDAT UDÁLOST sqlserver.lock_releasedADD TARGET package0.event_file(SET název_souboru=N'Locks',max_file_size=(5),max_4)WIMORY_FIles==4096 KB,MEMORY_PARTITION_MODE=NONE,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_EVENT_SIZE=0 kB);
Poznámka:Toto není relace události, kterou bych kdy doporučil spouštět při produkčním zatížení – objem dat, který by vygenerovala, by byl významný, protože sleduje každé získání a uvolnění zámku.
Pokud spustíme tuto relaci a poté spustíme generátor pracovní zátěže AdventureWorks Books Online, který je k dispozici na mém blogu proti instanci SQL Server, relace začne rychle vynechávat události kvůli rychlému generování událostí a zpoždění vyprázdnění vyrovnávací paměti do cíle event_file. který je nakonfigurován. Počet událostí, které byly zrušeny relací události, lze sledovat v sys.dm_xe_sessions DMV, pokud byly možnosti relace události nakonfigurovány s EVENT_RETENTION_MODE =ALLOW_SINGLE_EVENT_LOSS. Pokud je relace události nakonfigurována s EVENT_RETENTION_MODE=ALLOW_MULTIPLE_EVENT_LOSS, pak lze zahodit celé vyrovnávací paměti událostí a počítá se pouze, kolik vyrovnávacích pamětí bylo zahozeno, nikoli počet jednotlivých událostí, které každá vyrovnávací paměť obsahuje.
SELECT s.name, s.total_regular_buffers, s.regular_buffer_size, s.total_large_buffers, s.large_buffer_size, s.dropped_event_count, s.dropped_buffer_count, s.largest_event_dropped_sizeFROM sysses.dm_x
Zde můžeme vidět, že bylo zahozeno 100 521 událostí a největší velikost události, která byla zahozena, byla 176 bajtů, což je menší než velikost našeho běžného prostoru vyrovnávací paměti, takže právě narážíme na normální tlak vyrovnávací paměti. Pokud však vytvoříme relaci události, která shromažďuje dvě z událostí showplanu (viz tento článek, proč to vážně ovlivní výkon a nemělo by se to provádět na produkčních serverech), spolu s událostmi spuštění a dokončení dávky a vygenerovat nějaké větší plány, můžeme spustit ztrátu události kvůli velikosti události.
VYTVOŘIT RELACI UDÁLOSTI [DropsEvents] NA SERVERU PŘIDAT UDÁLOST sqlserver.query_post_execution_showplan,PŘIDAT UDÁLOST sqlserver.query_pre_execution_showplan,ADD UDÁLOST sqlserver.sql_batch_completed,qADDl>
Zde vidíme, že největší_event_poklesnutá_velikost je větší než naše regular_buffer_size, takže to znamená, že musíme změnit konfiguraci vyrovnávacích pamětí relací. Pokud zvýšíme MAX_MEMORY pro relaci události, může to zvětšit velikost našich běžných vyrovnávacích pamětí. Výchozí hodnota je pouze 4 MB, odkud pochází výše uvedená velikost vyrovnávací paměti 1,4 MB. Pokud toto změníme na 64 MB pro relaci události, regular_buffer_size bude mít velikost 22,4 MB, což by vyhovovalo naší 3,7 MB vynechané události. Druhou možností je nastavit možnost MAX_EVENT_SIZE, která poskytuje large_buffer_size pro velké události a je pro relaci dělená dvěma.
Vytvoření relace událostí [CollectSevents] na serveru Add Event SQLSERVER.Query_Post_Execution_showplan, přidat událost sqlserver.Query_Pre_Execution_showplan, přidat events sqls50, maxis5, maxis5, maxis5, maxis5, maxis5, maxis5, ad, maxis5, ad, maxis55555555555555555555555555555555555555555.
Zde tedy vidíme dvě velké vyrovnávací paměti o velikosti 33,6 MB a po opětovném spuštění stejného plánu generujícího pracovní zátěž nemáme žádné vyřazené události pro naši novou relaci CollectsEvents, ale zdvojnásobili jsme zahozené události pro naši relaci DropsEvents pomocí výchozích nastavení.
Takže, tady to máte; proč určité události nemusí být shromážděny relací události, jak postupovat při odstraňování problémů, když jsou události zrušeny, a jak určit, zda je příčinou problém velikost události. Mnoho relací, které vidím ve skutečném použití na klientských systémech, má výchozí hodnoty pro možnosti relací událostí, zejména pokud jde o paměť. Toto je jedna oblast, ve které, jakmile pochopíte mechanismus ukládání do vyrovnávací paměti používaný Extended Events, a poté zvážíte velikost událostí, které by mohly být potenciálně generovány, začnete provádět změny v tom, jak jsou definovány možnosti relace, abyste minimalizovali potenciál událostí. zahozena kvůli omezením místa v paměti nebo omezením velikosti události.
