Måling af "Observer Overhead" af SQL Trace vs. Extended Events

SQL Server tilbyder to metoder til indsamling af diagnosticerings- og fejlfindingsdata om den arbejdsbelastning, der udføres mod serveren:SQL Trace og Extended Events. Startende i SQL Server 2012 giver Extended Events-implementeringen sammenlignelige dataindsamlingsmuligheder med SQL Trace og kan bruges til sammenligninger af de overhead, der påløber af disse to funktioner. I denne artikel tager vi et kig på at sammenligne "observatør-overhead", der opstår, når du bruger SQL Trace og Extended Events i forskellige konfigurationer for at bestemme den præstationsindvirkning, som dataindsamling kan have på vores arbejdsbyrde ved brug af en genafspilningsarbejdsbelastning capture og distribueret genafspilning.

Testmiljøet

Testmiljøet består af seks virtuelle maskiner, en domænecontroller, en SQL Server 2012 Enterprise-udgaveserver og fire klientservere med Distributed Replay-klienttjenesten installeret på dem. Forskellige værtskonfigurationer blev testet for denne artikel, og lignende resultater resulterede fra de tre forskellige konfigurationer, der blev testet baseret på forholdet mellem påvirkning. SQL Server Enterprise Edition-serveren er konfigureret med 4 vCPU'er og 4 GB RAM. De resterende fem servere er konfigureret med 1 vCPU og 1 GB RAM. Tjenesten Distributed Replay-controller blev kørt på SQL Server 2012 Enterprise-udgaveserveren, fordi den kræver en Enterprise-licens for at bruge mere end én klient til genafspilning.

Test arbejdsbelastning

Testarbejdsbyrden, der bruges til genafspilningsoptagelsen, er AdventureWorks Books Online-arbejdsbelastningen, som jeg oprettede sidste år til at generere falske arbejdsbelastninger mod SQL Server. Denne arbejdsbyrde bruger eksempelforespørgslerne fra Books Online mod AdventureWorks-familien af ​​databaser og er drevet af PowerShell. Arbejdsbyrden blev sat op på hver af de fire replay-klienter og kørte med fire samlede forbindelser til SQL Serveren fra hver af klientserverne for at generere en 1GB replay-sporing. Replay-sporingen blev oprettet ved hjælp af TSQL_Replay-skabelonen fra SQL Server Profiler, eksporteret til et script og konfigureret som en serverside-sporing til en fil. Når replay-sporingsfilen blev fanget, blev den forbehandlet til brug med Distributed Replay, og derefter blev replay-dataene brugt som replay-arbejdsbelastning for alle testene.

Genafspil konfiguration

Genafspilningsoperationen blev konfigureret til at bruge stresstilstandskonfiguration til at drive den maksimale mængde belastning mod test SQL Server-forekomsten. Derudover bruger konfigurationen en reduceret tænk og tilslut tidsskala, som justerer forholdet mellem tid mellem starten af ​​genafspilningssporet, og hvornår en hændelse faktisk fandt sted, til hvornår den afspilles under genafspilningsoperationen, for at tillade hændelserne at blive afspillet kl. maksimal skala. Stressskalaen for replayet er også konfigureret pr. spid. Detaljerne for konfigurationsfilen for genafspilningsoperationen var som følger:

<?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>

Under hver af gentagelsesoperationerne blev præstationstællere indsamlet i fem sekunders intervaller for følgende tællere:

• Processor\% Processortid\_Total
• SQL-server\SQL-statistik\Batch-anmodninger/sek.

Disse tællere vil blive brugt til at måle den samlede serverbelastning og gennemløbsegenskaberne for hver af testene til sammenligning.

Test konfigurationer

I alt syv forskellige konfigurationer blev testet med Distributed Replay:

• Basislinje
• Sporing på serversiden
• Profil på serveren
• Fjernprofiler
• Udvidede begivenheder til begivenhedsfil
• Udvidede begivenheder til ring_buffer
• Udvidede begivenheder til event_stream

Hver test blev gentaget tre gange for at sikre, at resultaterne var konsistente på tværs af forskellige tests og for at give et gennemsnitligt sæt resultater til sammenligning. Til de indledende baseline-tests blev der ikke konfigureret yderligere dataindsamling for SQL Server-forekomsten, men standarddatasamlingerne, der leveres med SQL Server 2012, blev efterladt aktiveret:standardsporingen og system_health-hændelsessessionen. Dette afspejler den generelle konfiguration af de fleste SQL-servere, da det generelt ikke anbefales, at standardtrace- eller system_health-sessionen deaktiveres på grund af de fordele, de giver databaseadministratorer. Denne test blev brugt til at bestemme den overordnede baseline til sammenligning med de test, hvor der blev udført yderligere dataindsamling. De resterende test er baseret på TSQL_SPs skabelon, der leveres med SQL Server Profiler og indsamler følgende hændelser:

• Sikkerhedsrevision\Revisionslogin
• Sikkerhedsrevision\Revisionslog ud
• Sessioner\ExistingConnection
• Lagrede procedurer\RPC:Starter
• Lagrede procedurer\SP:Fuldført
• Lagrede procedurer\SP:Starter
• Lagrede procedurer\SP:StmtStarting
• TSQL\SQL:BatchStarting

Denne skabelon blev valgt baseret på den arbejdsbyrde, der blev brugt til testene, som primært er SQL-batches, der er fanget af SQL:BatchStarting hændelse, og derefter et antal hændelser ved hjælp af de forskellige metoder i hierarchyid , som er fanget af SP:Starting , SP:StmtStarting , og SP:Completed begivenheder. Et sporingsscript på serversiden blev genereret fra skabelonen ved hjælp af eksportfunktionaliteten i SQL Server Profiler, og de eneste ændringer, der blev foretaget i scriptet, var at indstille maxfilesize parameter til 500 MB, aktiver sporingsfil rollover, og angiv et filnavn, som sporingen blev skrevet til.

Den tredje og fjerde test brugte SQL Server Profiler til at indsamle de samme hændelser som sporingen på serversiden for at måle ydeevneoverhead ved sporing ved hjælp af Profiler-applikationen. Disse test blev kørt ved hjælp af SQL Profiler lokalt på SQL Serveren og eksternt fra en separat klient for at fastslå, om der var en forskel i overhead ved at have Profiler kørende lokalt eller eksternt.

De sidste tests, der blev brugt Extended Events indsamlede de samme hændelser og de samme kolonner baseret på en hændelsessession oprettet ved hjælp af mit Trace to Extended Events konverteringsscript til SQL Server 2012. Testene omfattede evaluering af hændelsesfilen, ring_buffer og den nye streamingudbyder i SQL Server 2012 separat for at bestemme den overhead, som hvert mål kan pålægge serverens ydeevne. Derudover blev hændelsessessionen konfigureret med standardindstillingerne for hukommelsesbuffer, men blev ændret til at specificere NO_EVENT_LOSS for EVENT_RETENTION_MODE mulighed for hændelsesfil- og ringbuffertestene for at matche adfærden for sporing på serversiden til en fil, hvilket også garanterer, at der ikke går tab af hændelser.

Resultater

Med én undtagelse var resultaterne af testene ikke overraskende. Baseline-testen var i stand til at udføre replay-arbejdsbelastningen på tretten minutter og femogtredive sekunder og havde i gennemsnit 2345 batch-anmodninger pr. sekund under testene. Med sporing på serversiden kørte genafspilningsoperationen på 16 minutter og 40 sekunder, hvilket er en 18,1 % forringelse af ydeevnen. Profiler Traces havde de dårligste resultater generelt og krævede 149 minutter, når Profiler blev kørt lokalt på serveren, og 123 minutter og 20 sekunder, når Profiler blev kørt eksternt, hvilket gav henholdsvis 90,8 % og 87,6 % forringelse af ydeevnen. Extended Events-testene var de bedste, der tog 15 minutter og 15 sekunder for event_filen og 15 minutter og 40 sekunder for ring_buffer-målet, hvilket resulterede i en 10,4 % og 11,6 % forringelse af ydeevnen. Gennemsnitsresultaterne for alle test er vist i tabel 1 og kortlagt i figur 2:

Tabel 1 – Gennemsnitlige resultater af alle test

Figur 2 – Diagram over resultater

Extended Events-streamingtesten er ikke helt et retfærdigt resultat i sammenhæng med de test, der blev kørt, og kræver lidt mere forklaring for at forstå resultatet. Fra tabelresultaterne kan vi se, at streamingtestene for udvidede begivenheder blev gennemført på seksten minutter og femogtredive sekunder, hvilket svarer til 34,1 % forringelse af ydeevnen. Men hvis vi zoomer ind på diagrammet og ændrer dets skala, som vist i figur 3, vil vi se, at streamingen havde en meget større indvirkning på ydeevnen i starten og derefter begyndte at udføre på samme måde som de andre Extended Events-tests. :

Figur 3 – Zoomede resultater ind

Forklaringen på dette findes i designet af det nye Extended Events-streamingmål i SQL Server 2012. Hvis de interne hukommelsesbuffere for event_stream fyldes op og ikke forbruges af klientapplikationen hurtigt nok, vil Database Engine tvinge en afbrydelse af event_stream for at forhindre alvorlig indvirkning på serverens ydeevne. Dette resulterer i, at der opstår en fejl i SQL Server 2012 Management Studio svarende til fejlen i figur 4:

Figur 4 – begivenhedsstrøm afbrudt af server

Konklusioner

Alle metoderne til indsamling af diagnosticeringsdata fra SQL Server har "observatoroverhead" forbundet med dem og kan påvirke ydeevnen af ​​en arbejdsbyrde under stor belastning. For systemer, der kører på SQL Server 2012, giver Extended Events den mindste mængde overhead og giver lignende muligheder for hændelser og kolonner som SQL Trace (nogle hændelser i SQL Trace rulles op til andre hændelser i Extended Events). Skulle SQL Trace være nødvendigt for at indfange hændelsesdata – hvilket kan være tilfældet, indtil tredjepartsværktøjer er omkodet for at udnytte data i Extended Events – vil en sporing på serversiden til en fil give den mindste mængde ydeevneoverhead. SQL Server Profiler er et værktøj, der skal undgås på travle produktionsservere, som vist ved den tidoblede stigning i varighed og betydelig reduktion i gennemløbet for genafspilningen.

Selvom resultaterne ser ud til at favorisere at køre SQL Server Profiler eksternt, når Profiler skal bruges, kan denne konklusion ikke drages endeligt baseret på de specifikke test, der blev kørt i dette scenarie. Yderligere test og dataindsamling skal udføres for at afgøre, om de eksterne Profiler-resultater var resultatet af lavere kontekstskift på SQL Server-instansen, eller om netværk mellem VM'er spillede en faktor i den lavere ydeevnepåvirkning på fjernindsamlingen. Pointen i disse test var at vise den betydelige overhead, som Profiler pådrager sig, uanset hvor Profiler blev kørt. Endelig har live-begivenhedsstreamen i Extended Events også en høj overhead, når den rent faktisk er forbundet med at indsamle data, men som vist i testene, vil Database Engine afbryde en livestream, hvis den kommer bagud med begivenhederne for at forhindre alvorlig påvirkning af serverens ydeevne.