Meten van "Observer Overhead" van SQL Trace versus uitgebreide gebeurtenissen

SQL Server biedt twee methoden voor het verzamelen van diagnostische en probleemoplossingsgegevens over de werkbelasting die op de server wordt uitgevoerd:SQL Trace en Extended Events. Vanaf SQL Server 2012 biedt de Extended Events-implementatie vergelijkbare mogelijkheden voor het verzamelen van gegevens als SQL Trace en kan worden gebruikt voor vergelijkingen van de overhead die door deze twee functies wordt veroorzaakt. In dit artikel zullen we kijken naar het vergelijken van de "observer overhead" die optreedt bij het gebruik van SQL Trace en Extended Events in verschillende configuraties om de prestatie-impact te bepalen die gegevensverzameling kan hebben op onze workload door het gebruik van een replay workload vastleggen en gedistribueerde herhaling.

De testomgeving

De testomgeving bestaat uit zes virtuele machines, één domeincontroller, één SQL Server 2012 Enterprise Edition-server en vier clientservers waarop de Distributed Replay-clientservice is geïnstalleerd. Er zijn verschillende hostconfiguraties getest voor dit artikel en vergelijkbare resultaten kwamen voort uit de drie verschillende configuraties die werden getest op basis van de impactverhouding. De SQL Server Enterprise Edition-server is geconfigureerd met 4 vCPU's en 4 GB RAM. De overige vijf servers zijn geconfigureerd met 1 vCPU en 1GB RAM. De Distributed Replay-controllerservice werd uitgevoerd op de SQL Server 2012 Enterprise Edition-server omdat er een Enterprise-licentie voor nodig is om meer dan één client voor replay te gebruiken.

Test werklast

De testworkload die wordt gebruikt voor het vastleggen van de herhaling is de AdventureWorks Books Online-workload die ik vorig jaar heb gemaakt voor het genereren van nep-workloads tegen SQL Server. Deze workload gebruikt de voorbeeldquery's van de Books Online tegen de AdventureWorks-databases en wordt aangestuurd door PowerShell. De workload werd ingesteld op elk van de vier replay-clients en uitgevoerd met in totaal vier verbindingen met de SQL Server vanaf elk van de clientservers om een ​​replay-tracering van 1 GB te genereren. De replay-tracering is gemaakt met behulp van de TSQL_Replay-sjabloon van SQL Server Profiler, geëxporteerd naar een script en geconfigureerd als een server-side-tracering naar een bestand. Nadat het replay-traceerbestand was vastgelegd, werd het voorverwerkt voor gebruik met Distributed Replay en vervolgens werden de replay-gegevens gebruikt als de replay-werkbelasting voor alle tests.

Configuratie opnieuw afspelen

De herhalingsbewerking is geconfigureerd om de configuratie van de stressmodus te gebruiken om de maximale hoeveelheid belasting voor het testexemplaar van SQL Server te genereren. Bovendien maakt de configuratie gebruik van een verkorte denk- en verbindingstijdschaal, die de verhouding van de tijd tussen het begin van het herhalingsspoor en het moment waarop een gebeurtenis zich daadwerkelijk heeft voorgedaan en het moment waarop deze tijdens de herhalingsbewerking wordt afgespeeld, aanpast, zodat de gebeurtenissen kunnen worden afgespeeld op maximale schaal. De stressschaal voor de replay wordt ook per spid geconfigureerd. De details van het configuratiebestand voor de herhalingsbewerking waren als volgt:

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

Tijdens elk van de herhalingen werden prestatietellers verzameld met intervallen van vijf seconden voor de volgende tellers:

• Processor\% Processortijd\_Totaal
• SQL Server\SQL Statistics\Batch Requests/sec

Deze tellers worden gebruikt om de algehele serverbelasting te meten en de doorvoerkenmerken van elk van de tests ter vergelijking.

Testconfiguraties

Er zijn in totaal zeven verschillende configuraties getest met Distributed Replay:

• Basislijn
• Server-side traceren
• Profiler op server
• Profiler op afstand
• Uitgebreide evenementen naar event_file
• Uitgebreide gebeurtenissen naar ring_buffer
• Uitgebreide evenementen naar event_stream

Elke test werd drie keer herhaald om ervoor te zorgen dat de resultaten consistent waren in verschillende tests en om een ​​gemiddelde set resultaten te geven ter vergelijking. Voor de eerste basislijntests is er geen aanvullende gegevensverzameling geconfigureerd voor het SQL Server-exemplaar, maar de standaardgegevensverzamelingen die bij SQL Server 2012 worden geleverd, bleven ingeschakeld:de standaardtracering en de gebeurtenissessie system_health. Dit weerspiegelt de algemene configuratie van de meeste SQL-servers, aangezien het over het algemeen niet wordt aanbevolen om de standaardtracering of system_health-sessie uit te schakelen vanwege de voordelen die ze bieden aan databasebeheerders. Deze test werd gebruikt om de algemene basislijn te bepalen voor vergelijking met de tests waarbij aanvullende gegevensverzameling werd uitgevoerd. De overige tests zijn gebaseerd op de TSQL_SPs-sjabloon die wordt geleverd met SQL Server Profiler en verzamelt de volgende gebeurtenissen:

• Beveiligingsaudit\Audit Login
• Beveiligingsaudit\Audit Uitloggen
• Sessions\ExistingConnection
• Opgeslagen procedures\RPC:Bezig met starten
• Opgeslagen procedures\SP:voltooid
• Opgeslagen procedures\SP:Begin
• Opgeslagen procedures\SP:StmtStarting
• TSQL\SQL:BatchBegint

Deze sjabloon is geselecteerd op basis van de werkbelasting die voor de tests wordt gebruikt, voornamelijk SQL-batches die worden vastgelegd door de SQL:BatchStarting gebeurtenis, en vervolgens een aantal gebeurtenissen met behulp van de verschillende methoden van hierarchyid , die worden vastgelegd door de SP:Starting , SP:StmtStarting , en SP:Completed evenementen. Er is een traceerscript aan de serverzijde gegenereerd op basis van de sjabloon met behulp van de exportfunctionaliteit in SQL Server Profiler, en de enige wijzigingen die in het script zijn aangebracht, waren het instellen van de maxfilesize parameter in op 500 MB, zet traceerbestand rollover aan en geef een bestandsnaam op waarnaar de tracering is geschreven.

Bij de derde en vierde test werd SQL Server Profiler gebruikt om dezelfde gebeurtenissen te verzamelen als de tracering aan de serverzijde om de prestatie-overhead van tracering met behulp van de Profiler-toepassing te meten. Deze tests zijn uitgevoerd met SQL Profiler lokaal op de SQL Server en op afstand vanaf een afzonderlijke client om vast te stellen of er een verschil was in overhead door Profiler lokaal of op afstand te laten draaien.

De laatste tests die Extended Events gebruikten, verzamelden dezelfde gebeurtenissen en dezelfde kolommen op basis van een gebeurtenissessie die was gemaakt met mijn Trace to Extended Events-conversiescript voor SQL Server 2012. De tests omvatten het evalueren van het gebeurtenisbestand, de ringbuffer en de nieuwe streamingprovider in SQL Server 2012 afzonderlijk om de overhead te bepalen die elk doel zou kunnen opleggen aan de prestaties van de server. Bovendien is de gebeurtenissessie geconfigureerd met de standaard geheugenbufferopties, maar gewijzigd om NO_EVENT_LOSS op te geven. voor de EVENT_RETENTION_MODE optie voor de event_file- en ring_buffer-tests om het gedrag van server-side Trace af te stemmen op een bestand, wat ook garandeert dat er geen eventverlies optreedt.

Resultaten

Op één uitzondering na waren de resultaten van de tests niet verrassend. De basislijntest was in staat om de replay-werklast in dertien minuten en vijfendertig seconden uit te voeren, en had tijdens de tests een gemiddelde van 2345 batchverzoeken per seconde. Terwijl Trace aan de serverzijde actief was, voltooide de herhalingsbewerking in 16 minuten en 40 seconden, wat een prestatievermindering van 18,1% is. De Profiler Traces presteerden in het algemeen het slechtst en hadden 149 minuten nodig wanneer Profiler lokaal op de server werd uitgevoerd, en 123 minuten en 20 seconden wanneer Profiler op afstand werd uitgevoerd, wat neerkwam op een prestatievermindering van respectievelijk 90,8% en 87,6%. De Extended Events-tests presteerden het best en namen 15 minuten en 15 seconden in beslag voor het event_file en 15 minuten en 40 seconden voor het ring_buffer-doel, wat resulteerde in een prestatievermindering van 10,4% en 11,6%. De gemiddelde resultaten voor alle tests worden weergegeven in tabel 1 en weergegeven in afbeelding 2:

Tabel 1 – Gemiddelde resultaten van alle tests

Figuur 2 – Resultatenoverzicht

De Extended Events streaming-test is niet helemaal een eerlijk resultaat in de context van de tests die zijn uitgevoerd en vereist wat meer uitleg om het resultaat te begrijpen. Uit de tabelresultaten kunnen we zien dat de streamingtests voor Extended Events voltooid zijn in zestien minuten en vijfendertig seconden, wat neerkomt op een prestatievermindering van 34,1%. Als we echter inzoomen op de grafiek en de schaal wijzigen, zoals weergegeven in afbeelding 3, zullen we zien dat de streaming aanvankelijk een veel grotere impact had op de prestaties en vervolgens begon te presteren op een manier die vergelijkbaar is met de andere Extended Events-tests :

Figuur 3 – Ingezoomde resultaten

De verklaring hiervoor is te vinden in het ontwerp van het nieuwe Extended Events-streamingdoel in SQL Server 2012. Als de interne geheugenbuffers voor de event_stream vol raken en niet snel genoeg door de clienttoepassing worden verbruikt, dwingt de Database Engine de verbinding met de event_stream om te voorkomen dat de serverprestaties ernstig worden beïnvloed. Dit resulteert in een fout die wordt gegenereerd in SQL Server 2012 Management Studio, vergelijkbaar met de fout in Afbeelding 4:

Figuur 4 – event_stream verbroken door server

Conclusies

Alle methoden voor het verzamelen van diagnostische gegevens van SQL Server hebben een 'observer-overhead' en kunnen de prestaties van een werkbelasting onder zware belasting beïnvloeden. Voor systemen die op SQL Server 2012 worden uitgevoerd, bieden uitgebreide gebeurtenissen de minste hoeveelheid overhead en bieden vergelijkbare mogelijkheden voor gebeurtenissen en kolommen als SQL Trace (sommige gebeurtenissen in SQL Trace worden samengevoegd tot andere gebeurtenissen in Uitgebreide gebeurtenissen). Mocht SQL Trace nodig zijn voor het vastleggen van gebeurtenisgegevens - wat het geval kan zijn totdat tools van derden zijn gehercodeerd om gebruik te maken van Extended Events-gegevens - dan levert een server-side Trace naar een bestand de minste hoeveelheid prestatieoverhead op. SQL Server Profiler is een tool die moet worden vermeden op drukke productieservers, zoals blijkt uit de tienvoudige toename van de duur en aanzienlijke vermindering van de doorvoer voor de herhaling.

Hoewel de resultaten de voorkeur lijken te geven aan het op afstand uitvoeren van SQL Server Profiler wanneer Profiler moet worden gebruikt, kan deze conclusie niet definitief worden getrokken op basis van de specifieke tests die in dit scenario zijn uitgevoerd. Er zouden aanvullende tests en gegevensverzameling moeten worden uitgevoerd om te bepalen of de externe Profiler-resultaten het resultaat waren van een lagere contextomschakeling op de SQL Server-instantie, of dat netwerken tussen VM's een factor speelden in de lagere prestatie-impact op de externe verzameling. Het doel van deze tests was om de aanzienlijke overhead aan te tonen die Profiler maakt, ongeacht waar Profiler werd uitgevoerd. Ten slotte heeft de live-gebeurtenisstream in Extended Events ook een hoge overhead wanneer deze daadwerkelijk is aangesloten bij het verzamelen van gegevens, maar zoals blijkt uit de tests, zal de Database Engine een livestream loskoppelen als deze achterloopt op de gebeurtenissen om ernstige gevolgen voor de prestatie van de server.