Database
 sql >> Datenbank >  >> RDS >> Database

Messung des „Beobachter-Overheads“ von SQL Trace vs. Extended Events

SQL Server bietet zwei Methoden zum Sammeln von Diagnose- und Problembehandlungsdaten über die auf dem Server ausgeführte Arbeitslast:SQL-Ablaufverfolgung und erweiterte Ereignisse. Ab SQL Server 2012 bietet die Extended Events-Implementierung vergleichbare Datenerfassungsfunktionen wie die SQL-Ablaufverfolgung und kann für Vergleiche des Overheads verwendet werden, der durch diese beiden Features entsteht. In diesem Artikel werfen wir einen Blick auf den Vergleich des „Beobachter-Overheads“, der bei der Verwendung von SQL-Ablaufverfolgung und erweiterten Ereignissen in verschiedenen Konfigurationen auftritt, um die Leistungsauswirkungen zu bestimmen, die die Datenerfassung auf unsere Arbeitsauslastung durch die Verwendung einer Wiedergabe-Arbeitsauslastung haben kann Erfassung und verteilte Wiedergabe.

Die Testumgebung

Die Testumgebung besteht aus sechs virtuellen Maschinen, einem Domänencontroller, einem SQL Server 2012 Enterprise Edition-Server und vier Clientservern, auf denen der Distributed Replay-Clientdienst installiert ist. Für diesen Artikel wurden verschiedene Host-Konfigurationen getestet, und ähnliche Ergebnisse ergaben sich aus den drei verschiedenen Konfigurationen, die basierend auf dem Verhältnis der Auswirkungen getestet wurden. Der SQL Server Enterprise Edition-Server ist mit 4 vCPUs und 4 GB RAM konfiguriert. Die restlichen fünf Server sind mit 1 vCPU und 1 GB RAM konfiguriert. Der Distributed Replay Controller-Dienst wurde auf dem SQL Server 2012 Enterprise Edition-Server ausgeführt, da er eine Enterprise-Lizenz erfordert, um mehr als einen Client für die Wiedergabe zu verwenden.

Arbeitsbelastung testen

Die für die Wiederholungserfassung verwendete Testworkload ist die AdventureWorks Books Online-Workload, die ich letztes Jahr zum Generieren von simulierten Workloads für SQL Server erstellt habe. Diese Workload verwendet die Beispielabfragen aus der Onlinedokumentation für Datenbanken der AdventureWorks-Familie und wird von PowerShell gesteuert. Die Workload wurde auf jedem der vier Replay-Clients eingerichtet und mit insgesamt vier Verbindungen zum SQL Server von jedem der Client-Server ausgeführt, um eine 1-GB-Replay-Trace-Erfassung zu generieren. Die Wiedergabeablaufverfolgung wurde mithilfe der Vorlage TSQL_Replay von SQL Server Profiler erstellt, in ein Skript exportiert und als serverseitige Ablaufverfolgung in einer Datei konfiguriert. Sobald die Replay-Trace-Datei erfasst wurde, wurde sie für die Verwendung mit Distributed Replay vorverarbeitet und dann wurden die Replay-Daten als Replay-Workload für alle Tests verwendet.

Wiedergabekonfiguration

Der Wiedergabevorgang wurde so konfiguriert, dass er die Belastungsmoduskonfiguration verwendet, um die maximale Lastmenge für die SQL Server-Testinstanz zu steuern. Darüber hinaus verwendet die Konfiguration eine reduzierte Think-and-Connect-Zeitskala, die das Zeitverhältnis zwischen dem Beginn der Wiedergabeablaufverfolgung und dem tatsächlichen Auftreten eines Ereignisses bis zu seiner Wiedergabe während des Wiedergabevorgangs anpasst, damit die Ereignisse wiedergegeben werden können maximale Skala. Die Belastungsskala für die Wiedergabe wird ebenfalls pro Spid konfiguriert. Die Details der Konfigurationsdatei für den Wiedergabevorgang waren wie folgt:

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

Während jeder der Wiedergabevorgänge wurden Leistungsindikatoren in Fünf-Sekunden-Intervallen für die folgenden Indikatoren erfasst:

  • Prozessor\Prozessorzeit in %\_Gesamt
  • SQL Server\SQL-Statistiken\Batch-Anforderungen/Sek.

Diese Zähler werden verwendet, um die Gesamtlast des Servers und die Durchsatzeigenschaften der einzelnen Tests zum Vergleich zu messen.

Konfigurationen testen

Insgesamt sieben verschiedene Konfigurationen wurden mit Distributed Replay getestet:

  • Grundlage
  • Serverseitige Ablaufverfolgung
  • Profiler auf dem Server
  • Profiler aus der Ferne
  • Erweiterte Ereignisse in event_file
  • Erweiterte Ereignisse zu ring_buffer
  • Erweiterte Ereignisse zu event_stream

Jeder Test wurde dreimal wiederholt, um sicherzustellen, dass die Ergebnisse über verschiedene Tests hinweg konsistent waren, und um einen durchschnittlichen Satz von Ergebnissen zum Vergleich bereitzustellen. Für die anfänglichen Basistests wurde keine zusätzliche Datensammlung für die SQL Server-Instanz konfiguriert, aber die Standarddatensammlungen, die mit SQL Server 2012 geliefert werden, wurden aktiviert gelassen:die Standardablaufverfolgung und die system_health-Ereignissitzung. Dies spiegelt die allgemeine Konfiguration der meisten SQL Server wider, da es aufgrund der Vorteile, die sie Datenbankadministratoren bieten, im Allgemeinen nicht empfohlen wird, die standardmäßige Trace- oder system_health-Sitzung zu deaktivieren. Dieser Test wurde verwendet, um die Gesamtbasislinie zum Vergleich mit den Tests zu bestimmen, bei denen eine zusätzliche Datensammlung durchgeführt wurde. Die verbleibenden Tests basieren auf der TSQL_SPs-Vorlage, die mit SQL Server Profiler geliefert wird und die folgenden Ereignisse erfasst:

  • Sicherheitsaudit\Audit-Login
  • Sicherheitsaudit\Audit-Abmeldung
  • Sitzungen\Bestehende Verbindung
  • Gespeicherte Prozeduren\RPC:Starten
  • Gespeicherte Prozeduren\SP:Abgeschlossen
  • Gespeicherte Prozeduren\SP:Starten
  • Gespeicherte Prozeduren\SP:StmtStarting
  • TSQL\SQL:BatchStart

Diese Vorlage wurde basierend auf der für die Tests verwendeten Arbeitslast ausgewählt, bei der es sich hauptsächlich um SQL-Batches handelt, die von SQL:BatchStarting erfasst werden event und dann eine Reihe von Events mit den verschiedenen Methoden von hierarchyid , die von SP:Starting erfasst werden , SP:StmtStarting , und SP:Completed Veranstaltungen. Ein serverseitiges Ablaufverfolgungsskript wurde mithilfe der Exportfunktion in SQL Server Profiler aus der Vorlage generiert, und die einzigen Änderungen, die am Skript vorgenommen wurden, waren das Festlegen von maxfilesize Parameter auf 500 MB setzen, Ablaufverfolgungsdatei-Rollover aktivieren und einen Dateinamen angeben, in den die Ablaufverfolgung geschrieben wurde.

Beim dritten und vierten Test wurden mit SQL Server Profiler dieselben Ereignisse wie bei der serverseitigen Ablaufverfolgung erfasst, um den Leistungsaufwand der Ablaufverfolgung mit der Profiler-Anwendung zu messen. Diese Tests wurden mit SQL Profiler lokal auf dem SQL Server und remote von einem separaten Client ausgeführt, um festzustellen, ob es einen Unterschied im Overhead gab, wenn Profiler lokal oder remote ausgeführt wurde.

Die abschließenden Tests, bei denen erweiterte Ereignisse verwendet wurden, sammelten dieselben Ereignisse und dieselben Spalten basierend auf einer Ereignissitzung, die mit meinem Konvertierungsskript „Verfolgung zu erweiterten Ereignissen“ für SQL Server 2012 erstellt wurde 2012 separat, um den Overhead zu bestimmen, den jedes Ziel möglicherweise auf die Leistung des Servers ausübt. Außerdem wurde die Ereignissitzung mit den standardmäßigen Speicherpufferoptionen konfiguriert, aber geändert, um NO_EVENT_LOSS anzugeben für den EVENT_RETENTION_MODE Option für die event_file- und ring_buffer-Tests, um das Verhalten des serverseitigen Trace auf eine Datei abzugleichen, was ebenfalls garantiert, dass kein Ereignis verloren geht.

Ergebnisse

Mit einer Ausnahme waren die Ergebnisse der Tests nicht überraschend. Der Baseline-Test konnte die Replay-Workload in dreizehn Minuten und fünfunddreißig Sekunden ausführen und erreichte während der Tests durchschnittlich 2345 Batch-Anforderungen pro Sekunde. Wenn die serverseitige Ablaufverfolgung ausgeführt wird, dauerte der Wiedergabevorgang 16 Minuten und 40 Sekunden, was einer Leistungsminderung von 18,1 % entspricht. Die Profiler-Ablaufverfolgungen hatten insgesamt die schlechtesten Leistungen und erforderten 149 Minuten, wenn Profiler lokal auf dem Server ausgeführt wurde, und 123 Minuten und 20 Sekunden, wenn Profiler remote ausgeführt wurde, was eine Leistungsminderung von 90,8 % bzw. 87,6 % ergab. Die Extended Events-Tests schnitten am besten ab und dauerten 15 Minuten und 15 Sekunden für das event_file und 15 Minuten und 40 Sekunden für das ring_buffer-Ziel, was zu einer 10,4-prozentigen und 11,6-prozentigen Verschlechterung der Leistung führte. Die durchschnittlichen Ergebnisse für alle Tests sind in Tabelle 1 dargestellt und in Abbildung 2 grafisch dargestellt:


Tabelle 1 – Durchschnittsergebnisse aller Tests


Abbildung 2 – Ergebnisdiagramm

Der Extended Events Streaming-Test ist im Kontext der durchgeführten Tests kein ganz faires Ergebnis und erfordert etwas mehr Erklärung, um das Ergebnis zu verstehen. Aus den Tabellenergebnissen können wir ersehen, dass die Streaming-Tests für erweiterte Ereignisse in sechzehn Minuten und fünfunddreißig Sekunden abgeschlossen waren, was einer Leistungsminderung von 34,1 % entspricht. Wenn wir jedoch in das Diagramm hineinzoomen und seine Skalierung ändern, wie in Abbildung 3 gezeigt, sehen wir, dass das Streaming anfangs einen viel größeren Einfluss auf die Leistung hatte und dann anfing, sich ähnlich wie die anderen Tests für erweiterte Ereignisse zu verhalten :


Abbildung 3 – Vergrößerte Ergebnisse

Die Erklärung dafür findet sich im Design des neuen Streamingziels Extended Events in SQL Server 2012. Wenn die internen Speicherpuffer für event_stream voll sind und nicht schnell genug von der Clientanwendung verbraucht werden, erzwingt die Datenbank-Engine eine Trennung von den event_stream, um zu verhindern, dass die Serverleistung stark beeinträchtigt wird. Dies führt dazu, dass in SQL Server 2012 Management Studio ein ähnlicher Fehler wie in Abbildung 4 ausgelöst wird:


Abbildung 4 – event_stream vom Server getrennt

Während der Ereignisaufzählung ist eine Ausnahme aufgetreten. Untersuchen Sie die innere Ausnahme auf weitere Informationen.
(Microsoft.SqlServer.XEvent.Linq)

Fehler 25726, Schweregrad 17, Status 0 wurde ausgelöst, aber darin wurde keine Nachricht mit dieser Fehlernummer gefunden sys.messages. Wenn der Fehler größer als 50000 ist, stellen Sie sicher, dass die benutzerdefinierte Nachricht mit sp_addmessage hinzugefügt wird.
(Microsoft SQL Server, Fehler:18054)

Schlussfolgerungen

Allen Methoden zum Sammeln von Diagnosedaten von SQL Server ist ein „Beobachter-Overhead“ zugeordnet, der die Leistung einer Arbeitsauslastung unter hoher Last beeinträchtigen kann. Für Systeme, die auf SQL Server 2012 ausgeführt werden, bieten erweiterte Ereignisse den geringsten Overhead und bieten ähnliche Funktionen für Ereignisse und Spalten wie die SQL-Ablaufverfolgung (einige Ereignisse in der SQL-Ablaufverfolgung werden in andere Ereignisse in erweiterten Ereignissen eingerollt). Sollte SQL Trace zum Erfassen von Ereignisdaten erforderlich sein – was der Fall sein kann, bis Tools von Drittanbietern neu codiert werden, um Extended Events-Daten zu nutzen – führt ein serverseitiges Trace zu einer Datei zu dem geringsten Leistungsaufwand. SQL Server Profiler ist ein Tool, das auf stark ausgelasteten Produktionsservern vermieden werden sollte, wie die Verzehnfachung der Dauer und die erhebliche Verringerung des Durchsatzes für die Wiedergabe zeigen.

Obwohl die Ergebnisse die Remoteausführung von SQL Server Profiler zu bevorzugen scheinen, wenn Profiler verwendet werden muss, kann diese Schlussfolgerung basierend auf den spezifischen Tests, die in diesem Szenario ausgeführt wurden, nicht endgültig gezogen werden. Zusätzliche Tests und Datenerfassung müssten durchgeführt werden, um festzustellen, ob die Remote-Profiler-Ergebnisse das Ergebnis eines geringeren Kontextwechsels auf der SQL Server-Instanz waren oder ob die Vernetzung zwischen VMs einen Faktor bei der geringeren Leistungsauswirkung auf die Remoteerfassung spielte. Bei diesen Tests ging es darum, den erheblichen Overhead zu zeigen, den Profiler verursacht, unabhängig davon, wo Profiler ausgeführt wurde. Schließlich hat der Live-Ereignis-Stream in Extended Events auch einen hohen Overhead, wenn er tatsächlich mit dem Sammeln von Daten verbunden ist, aber wie in den Tests gezeigt, trennt die Datenbank-Engine einen Live-Stream, wenn er mit den Ereignissen in Verzug gerät, um schwerwiegende Auswirkungen auf die zu verhindern Leistung des Servers.