Mätning av "Observer Overhead" av SQL Trace vs. Extended Events

SQL Server erbjuder två metoder för att samla in diagnostik och felsökningsdata om arbetsbelastningen som körs mot servern:SQL Trace och Extended Events. Från och med SQL Server 2012 ger Extended Events-implementeringen jämförbara datainsamlingsmöjligheter med SQL Trace och kan användas för jämförelser av de omkostnader som dessa två funktioner uppstår. I den här artikeln ska vi ta en titt på att jämföra "observatörsoverhead" som uppstår när du använder SQL Trace och Extended Events i olika konfigurationer för att avgöra vilken prestandapåverkan som datainsamling kan ha på vår arbetsbelastning genom att använda en replay-arbetsbelastning fånga och distribuerad uppspelning.

Testmiljön

Testmiljön består av sex virtuella maskiner, en domänkontrollant, en SQL Server 2012 Enterprise Edition-server och fyra klientservrar med Distributed Replay-klienttjänsten installerad på dem. Olika värdkonfigurationer testades för den här artikeln och liknande resultat resulterade från de tre olika konfigurationerna som testades baserat på förhållandet mellan påverkan. SQL Server Enterprise Edition-servern är konfigurerad med 4 vCPU:er och 4 GB RAM. De återstående fem servrarna är konfigurerade med 1 vCPU och 1 GB RAM. Tjänsten Distributed Replay Controller kördes på SQL Server 2012 Enterprise Edition-servern eftersom den kräver en Enterprise-licens för att använda mer än en klient för replay.

Testa arbetsbelastning

Testarbetsbelastningen som används för återuppspelningen är AdventureWorks Books Online-arbetsbelastningen som jag skapade förra året för att generera sken-arbetsbelastningar mot SQL Server. Denna arbetsbelastning använder exempelfrågorna från Books Online mot AdventureWorks-familjen av databaser och drivs av PowerShell. Arbetsbelastningen ställdes in på var och en av de fyra replay-klienterna och kördes med fyra totala anslutningar till SQL Server från var och en av klientservrarna för att generera en 1GB replay-spårning. Uppspelningsspåret skapades med hjälp av mallen TSQL_Replay från SQL Server Profiler, exporterades till ett skript och konfigurerades som ett spårning på serversidan till en fil. När uppspelningsspårningsfilen väl var fångad förbehandlades den för användning med distribuerad återuppspelning och sedan användes uppspelningsdata som uppspelningsarbetsbelastning för alla tester.

Spela om konfiguration

Uppspelningsoperationen konfigurerades för att använda stresslägeskonfiguration för att driva den maximala mängden belastning mot test-SQL Server-instansen. Dessutom använder konfigurationen en reducerad tänk- och anslut-tidsskala, som justerar förhållandet mellan tiden mellan starten av uppspelningsspåret och när en händelse faktiskt inträffade till när den spelas upp under uppspelningsoperationen, för att tillåta händelserna att spelas upp kl. maximal skala. Stressskalan för reprisen är också konfigurerad per spid. Detaljerna för konfigurationsfilen för uppspelningsoperationen var följande:

<?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 var och en av reprisoperationerna samlades prestationsräknare in i fem sekunders intervaller för följande räknare:

• Processor\% Processortid\_Total
• SQL-server\SQL-statistik\batchförfrågningar/sek

Dessa räknare kommer att användas för att mäta den totala serverbelastningen och genomströmningsegenskaperna för vart och ett av testerna för jämförelse.

Testa konfigurationer

Totalt sju olika konfigurationer testades med Distributed Replay:

• Baslinje
• Spårning på serversidan
• Profiler på server
• Fjärrprofilera
• Utökade händelser till event_file
• Utökade händelser till ring_buffer
• Utökade händelser till event_stream

Varje test upprepades tre gånger för att säkerställa att resultaten var konsekventa över olika tester och för att ge en genomsnittlig uppsättning resultat för jämförelse. För de inledande baslinjetesterna konfigurerades ingen ytterligare datainsamling för SQL Server-instansen, men standarddatainsamlingarna som levereras med SQL Server 2012 lämnades aktiverade:standardspårningen och system_health-händelssessionen. Detta återspeglar den allmänna konfigurationen för de flesta SQL-servrar, eftersom det generellt inte rekommenderas att standardsessionen för spårning eller system_health inaktiveras på grund av fördelarna de ger databasadministratörer. Detta test användes för att bestämma den övergripande baslinjen för jämförelse med de tester där ytterligare datainsamling utfördes. De återstående testerna är baserade på TSQL_SPs mall som levereras med SQL Server Profiler och samlar in följande händelser:

• Säkerhetsrevision\Revisionsinloggning
• Säkerhetsrevision\Revision Logga ut
• Sessioner\ExistingConnection
• Lagrade procedurer\RPC:Startar
• Lagrade procedurer\SP:Slutförd
• Lagrade procedurer\SP:Startar
• Lagrade procedurer\SP:StmtStarting
• TSQL\SQL:BatchStarting

Den här mallen valdes baserat på den arbetsbelastning som användes för testerna, vilket i första hand är SQL-batcher som fångas upp av SQL:BatchStarting händelse, och sedan ett antal händelser med de olika metoderna för hierarchyid , som fångas upp av SP:Starting , SP:StmtStarting , och SP:Completed evenemang. Ett spårningsskript på serversidan genererades från mallen med hjälp av exportfunktionen i SQL Server Profiler, och de enda ändringar som gjordes i skriptet var att ställa in maxfilesize parameter till 500MB, aktivera spårningsfilövergång och ange ett filnamn som spårningen skrevs till.

De tredje och fjärde testerna använde SQL Server Profiler för att samla in samma händelser som spårningen på serversidan för att mäta prestandan för spårning med Profiler-applikationen. Dessa tester kördes med SQL Profiler lokalt på SQL Server och på distans från en separat klient för att fastställa om det fanns en skillnad i overhead genom att Profiler kördes lokalt eller på distans.

De sista testerna som användes för utökade händelser samlade in samma händelser och samma kolumner baserade på en händelsesession skapad med mitt konverteringsskript för spårning till utökade händelser för SQL Server 2012. Testerna inkluderade utvärdering av event_file, ring_buffer och ny streamingleverantör i SQL Server 2012 separat för att fastställa de overhead som varje mål kan medföra på serverns prestanda. Dessutom konfigurerades händelsesessionen med standardminnesbuffertalternativen, men ändrades för att ange NO_EVENT_LOSS för EVENT_RETENTION_MODE alternativet för testerna event_file och ring_buffer för att matcha beteendet för spårning på serversidan till en fil, vilket också garanterar ingen händelseförlust.

Resultat

Med ett undantag var resultaten av testerna inte överraskande. Baslinjetestet kunde utföra omspelningsarbetsbelastningen på tretton minuter och trettiofem sekunder och hade i genomsnitt 2345 batchförfrågningar per sekund under testerna. Med spårningen på serversidan igång slutfördes uppspelningen på 16 minuter och 40 sekunder, vilket är en prestandaförsämring på 18,1 %. Profiler Traces presterade sämst totalt sett och krävde 149 minuter när Profiler kördes lokalt på servern och 123 minuter och 20 sekunder när Profiler kördes på distans, vilket gav 90,8 % respektive 87,6 % försämring av prestanda. Extended Event-testerna var bäst presterande, och tog 15 minuter och 15 sekunder för event_filen och 15 minuter och 40 sekunder för ring_buffer-målet, vilket resulterade i en 10,4 % och 11,6 % försämring av prestanda. Genomsnittsresultaten för alla tester visas i tabell 1 och visas i figur 2:

Tabell 1 – Genomsnittliga resultat för alla tester

Figur 2 – Diagram över resultat

Strömningstestet Extended Events är inte riktigt ett rättvist resultat i samband med de tester som kördes och kräver lite mer förklaring för att förstå resultatet. Från tabellresultaten kan vi se att streamingtesterna för Extended Events slutfördes på sexton minuter och trettiofem sekunder, vilket motsvarar 34,1 % försämring i prestanda. Men om vi zoomar in i diagrammet och ändrar dess skala, som visas i figur 3, kommer vi att se att streamingen hade en mycket större inverkan på prestandan initialt och sedan började prestera på ett sätt som liknar de andra Extended Event-testerna :

Figur 3 – Zoomade in resultat

Förklaringen till detta finns i designen av det nya streamingmålet Extended Events i SQL Server 2012. Om de interna minnesbuffrarna för event_stream fylls upp och inte konsumeras av klientapplikationen snabbt nog, kommer databasmotorn att tvinga fram en frånkoppling av event_stream för att förhindra att serverns prestanda påverkas allvarligt. Detta resulterar i att ett fel uppstår i SQL Server 2012 Management Studio liknande felet i figur 4:

Figur 4 – händelseström frånkopplad av server

Slutsatser

Alla metoder för att samla in diagnostikdata från SQL Server har "observatörsoverhead" förknippade med dem och kan påverka prestandan för en arbetsbelastning under hög belastning. För system som körs på SQL Server 2012 ger Extended Events minsta möjliga overhead och ger liknande funktioner för händelser och kolumner som SQL Trace (vissa händelser i SQL Trace rullas upp till andra händelser i Extended Events). Skulle SQL Trace vara nödvändigt för att fånga händelsedata – vilket kan vara fallet tills tredjepartsverktyg kodas om för att dra nytta av Extended Events-data – kommer en spårning på serversidan till en fil att ge minsta möjliga prestandaoverhead. SQL Server Profiler är ett verktyg som ska undvikas på upptagna produktionsservrar, vilket framgår av den tiofaldiga ökningen av varaktigheten och betydande minskning av genomströmningen för reprisen.

Även om resultaten verkar gynna körning av SQL Server Profiler på distans när Profiler måste användas, kan denna slutsats inte definitivt dras baserat på de specifika tester som kördes i detta scenario. Ytterligare testning och datainsamling skulle behöva utföras för att avgöra om fjärrprofiler-resultaten var resultatet av lägre kontextväxling på SQL Server-instansen, eller om nätverk mellan virtuella datorer spelade en faktor i den lägre prestandapåverkan på fjärrinsamlingen. Poängen med dessa tester var att visa den betydande omkostnad som Profiler ådrar sig, oavsett var Profiler kördes. Slutligen har live-evenemangsströmmen i Extended Events också en hög omkostnad när den faktiskt är ansluten för att samla in data, men som visas i testerna kommer databasmotorn att koppla bort en liveström om den hamnar efter händelserna för att förhindra allvarlig påverkan på serverns prestanda.