Měření „režie pozorovatele“ trasování SQL vs. rozšířené události

SQL Server nabízí dvě metody shromažďování diagnostických dat a údajů o odstraňování problémů o pracovní zátěži prováděné na serveru:SQL Trace a Extended Events. Počínaje SQL Serverem 2012 poskytuje implementace Extended Events srovnatelné možnosti shromažďování dat jako SQL Trace a lze ji použít k porovnání režie vzniklé těmito dvěma funkcemi. V tomto článku se podíváme na porovnání „režie pozorovatele“, ke které dochází při použití SQL Trace a Extended Events v různých konfiguracích, abychom určili dopad na výkon, který může mít shromažďování dat na naši pracovní zátěž prostřednictvím použití pracovní zátěže přehrávání. zachycení a distribuované přehrávání.

Testovací prostředí

Testovací prostředí se skládá ze šesti virtuálních počítačů, jednoho řadiče domény, jednoho serveru SQL Server 2012 Enterprise edition a čtyř klientských serverů s nainstalovanou klientskou službou Distributed Replay. Pro tento článek byly testovány různé konfigurace hostitelů a podobné výsledky vyplynuly ze tří různých konfigurací, které byly testovány na základě poměru dopadu. Server SQL Server Enterprise Edition je konfigurován se 4 vCPU a 4 GB RAM. Zbývajících pět serverů je nakonfigurováno s 1 vCPU a 1 GB RAM. Služba řadiče Distributed Replay byla spuštěna na serveru SQL Server 2012 Enterprise Edition, protože k použití více než jednoho klienta pro přehrávání vyžaduje licenci Enterprise.

Testovací zátěž

Testovací zátěž používaná pro zachycení přehrávání je pracovní zátěž AdventureWorks Books Online, kterou jsem vytvořil minulý rok pro generování simulovaných úloh pro SQL Server. Tato úloha využívá vzorové dotazy z Books Online proti řadě databází AdventureWorks a je řízena prostředím PowerShell. Pracovní zátěž byla nastavena na každém ze čtyř klientů pro přehrávání a spuštěna se čtyřmi celkovými připojeními k serveru SQL z každého z klientských serverů, aby se vygenerovalo zachycení trasování přehrávání 1 GB. Trasování přehrávání bylo vytvořeno pomocí šablony TSQL_Replay z SQL Server Profiler, exportováno do skriptu a nakonfigurováno jako trasování na straně serveru do souboru. Jakmile byl soubor trasování přehrání zachycen, byl předzpracován pro použití s ​​distribuovaným přehráním a poté byla data přehrání použita jako pracovní zátěž přehrání pro všechny testy.

Konfigurace přehrávání

Operace přehrání byla nakonfigurována tak, aby používala konfiguraci zátěžového režimu pro maximální zatížení testovací instance SQL Server. Kromě toho konfigurace používá redukovanou časovou stupnici myšlení a připojení, která upravuje poměr času mezi začátkem trasování přehrání a okamžikem, kdy událost skutečně nastala, když je přehrána během operace přehrání, aby bylo možné události přehrát v maximální měřítko. Stupnice napětí pro přehrávání je také nakonfigurována pro každý bod. Podrobnosti konfiguračního souboru pro operaci přehrávání byly následující:

<?xml version="1.0" encoding="utf-8"?>
<Options>
  <ReplayOptions>
    <Server>SQL2K12-SVR1</Server>
    <SequencingMode>stress</SequencingMode>
    <ConnectTimeScale>1</ConnectTimeScale>
    <ThinkTimeScale>1</ThinkTimeScale>
    <HealthmonInterval>60</HealthmonInterval>
    <QueryTimeout>3600</QueryTimeout>
    <ThreadsPerClient>255</ThreadsPerClient>
    <EnableConnectionPooling>Yes</EnableConnectionPooling>
    <StressScaleGranularity>spid</StressScaleGranularity>
  </ReplayOptions>
  <OutputOptions>
    <ResultTrace>
      <RecordRowCount>No</RecordRowCount>
      <RecordResultSet>No</RecordResultSet>
    </ResultTrace>
  </OutputOptions>
</Options>

Během každé operace přehrávání byly čítače výkonu shromažďovány v pětisekundových intervalech pro následující čítače:

• Procesor\% času procesoru\_Celkový
• SQL Server\SQL Statistics\Batch Requests/s

Tyto čítače se použijí k měření celkového zatížení serveru a charakteristik propustnosti každého z testů pro srovnání.

Test konfigurace

S Distributed Replay bylo testováno celkem sedm různých konfigurací:

• Výchozí hodnota
• Trasování na straně serveru
• Profil na serveru
• Vzdáleně profilovat
• Rozšířené události na event_file
• Rozšířené události na ring_buffer
• Rozšířené události na event_stream

Každý test byl opakován třikrát, aby se zajistilo, že výsledky budou konzistentní v různých testech a aby se poskytl průměrný soubor výsledků pro srovnání. Pro počáteční základní testy nebylo pro instanci SQL Server nakonfigurováno žádné další shromažďování dat, ale výchozí shromažďování dat dodávané s SQL Server 2012 bylo ponecháno povolené:výchozí trasování a relace události system_health. To odráží obecnou konfiguraci většiny SQL Serverů, protože se obecně nedoporučuje deaktivovat výchozí trasování nebo relaci system_health kvůli výhodám, které poskytují správcům databází. Tento test byl použit ke stanovení celkové základní linie pro srovnání s testy, kde byl prováděn další sběr dat. Zbývající testy jsou založeny na šabloně TSQL_SPs, která se dodává s SQL Server Profiler a shromažďuje následující události:

• Audit zabezpečení\Přihlášení k auditu
• Bezpečnostní audit\Odhlášení z auditu
• Sessions\ExistingConnection
• Uložené procedury\RPC:Spouštění
• Uložené procedury\SP:Dokončeno
• Uložené procedury\SP:Spouštění
• Uložené procedury\SP:StmtStarting
• TSQL\SQL:BatchStarting

Tato šablona byla vybrána na základě zátěže použité pro testy, což jsou primárně dávky SQL, které zachycuje SQL:BatchStarting událost a poté řadu událostí pomocí různých metod hierarchyid , které jsou zachyceny SP:Starting , SP:StmtStarting a SP:Completed Události. Trasovací skript na straně serveru byl vygenerován ze šablony pomocí funkce exportu v SQL Server Profiler a jediné změny provedené ve skriptu byly nastavení maxfilesize parametr na 500 MB, povolit převrácení trasovacího souboru a poskytnout název souboru, do kterého bylo trasování zapsáno.

Třetí a čtvrtý test použil SQL Server Profiler ke shromažďování stejných událostí jako trasování na straně serveru k měření režie výkonu trasování pomocí aplikace Profiler. Tyto testy byly spuštěny pomocí SQL Profiler lokálně na SQL Serveru a vzdáleně ze samostatného klienta, aby se zjistilo, zda existuje rozdíl v režii tím, že Profiler běží lokálně nebo vzdáleně.

Poslední testy používané Extended Events shromáždily stejné události a stejné sloupce na základě relace události vytvořené pomocí mého konverzního skriptu Trace to Extended Events pro SQL Server 2012. Testy zahrnovaly vyhodnocení souboru event_file, ring_buffer a nového poskytovatele streamování na serveru SQL Server. 2012 samostatně, abyste určili režii, kterou může každý cíl představovat na výkon serveru. Kromě toho byla relace události nakonfigurována s výchozími možnostmi vyrovnávací paměti, ale byla změněna tak, aby specifikovala NO_EVENT_LOSS pro EVENT_RETENTION_MODE volba pro testy event_file a ring_buffer, aby odpovídala chování trasování na straně serveru k souboru, což také zaručuje žádnou ztrátu události.

Výsledky

Až na jednu výjimku výsledky testů nepřekvapily. Základní test byl schopen provést přehrání pracovní zátěže za třináct minut a třicet pět sekund a během testů měl průměrně 2345 dávkových požadavků za sekundu. Se spuštěným sledováním na straně serveru byla operace přehrávání dokončena za 16 minut a 40 sekund, což představuje 18,1% snížení výkonu. Profiler Traces měl celkově nejhorší výkon a vyžadoval 149 minut, když byl Profiler spuštěn lokálně na serveru, a 123 minut a 20 sekund, když byl Profiler spuštěn vzdáleně, což vedlo k 90,8% a 87,6% snížení výkonu v daném pořadí. Nejlépe dopadly testy Extended Events, které trvaly 15 minut a 15 sekund pro soubor event_file a 15 minut a 40 sekund pro cíl ring_buffer, což vedlo ke snížení výkonu o 10,4 % a 11,6 %. Průměrné výsledky všech testů jsou uvedeny v tabulce 1 a znázorněny na obrázku 2:

Tabulka 1 – Průměrné výsledky všech testů

Obrázek 2 – Tabulka výsledků

Test streamování Extended Events není zcela férový výsledek v kontextu testů, které byly spuštěny, a vyžaduje trochu více vysvětlení, abyste výsledek pochopili. Z tabulkových výsledků vidíme, že testy streamování pro Extended Events byly dokončeny za šestnáct minut a třicet pět sekund, což odpovídá 34,1% snížení výkonu. Pokud však graf přiblížíme a změníme jeho měřítko, jak je znázorněno na obrázku 3, uvidíme, že streamování mělo zpočátku mnohem větší dopad na výkon a poté začalo fungovat podobně jako ostatní testy Extended Events. :

Obrázek 3 – Přiblížené výsledky

Vysvětlení pro to lze nalézt v návrhu nového cíle streamování Extended Events v SQL Server 2012. Pokud se vyrovnávací paměti interní paměti pro proud událostí zaplní a nejsou dostatečně rychle spotřebovány klientskou aplikací, databázový stroj vynutí odpojení event_stream, aby se zabránilo vážnému dopadu na výkon serveru. Výsledkem je, že v SQL Server 2012 Management Studio se objeví chyba podobná chybě na obrázku 4:

Obrázek 4 – event_stream odpojený serverem

Závěry

Všechny metody shromažďování diagnostických dat ze serveru SQL Server mají spojenou „režii pozorovatele“ a mohou ovlivnit výkon zátěže při velkém zatížení. Pro systémy běžící na serveru SQL Server 2012 poskytují Extended Events nejmenší režii a poskytují podobné možnosti pro události a sloupce jako SQL Trace (některé události v SQL Trace jsou shrnuty do jiných událostí v Extended Events). Pokud je SQL Trace nezbytné pro zachycení dat událostí – což může být případ, dokud nebudou nástroje třetích stran překódovány tak, aby využívaly data Extended Events – trasování na straně serveru do souboru přinese nejmenší režii výkonu. SQL Server Profiler je nástroj, kterému je třeba se vyhnout na vytížených produkčních serverech, jak ukazuje desetinásobné prodloužení doby trvání a výrazné snížení propustnosti pro přehrávání.

I když se zdá, že výsledky upřednostňují vzdálené spuštění SQL Server Profiler, když je nutné použít Profiler, tento závěr nelze definitivně vyvodit na základě konkrétních testů, které byly v tomto scénáři spuštěny. Bylo by nutné provést další testování a shromažďování dat, aby se zjistilo, zda byly výsledky vzdáleného nástroje Profiler výsledkem nižšího přepínání kontextu na instanci SQL Server, nebo zda síť mezi virtuálními počítači hrála faktor v nižším dopadu na výkon vzdálené kolekce. Cílem těchto testů bylo ukázat významnou režii, kterou Profiler vynakládá, bez ohledu na to, kde byl Profiler spuštěn. A konečně, stream živých událostí v Extended Events má také vysokou režii, když je skutečně připojen ke shromažďování dat, ale jak se ukázalo v testech, databázový stroj odpojí živý stream, pokud zaostává za událostmi, aby se zabránilo vážnému dopadu na výkonu serveru.