In diesem Beitrag werde ich eine allgemeine Methode zur Fehlerbehebung bei CPU-Leistungsproblemen diskutieren. Ich mag es, Methoden standardmäßig anzuwenden, und ich mag es auch, auf der Grundlage früherer Erfahrungen Effizienzen bei der Problembehebung aufzubauen. Ohne einen allgemeinen Rahmen wird es allzu leicht, mitten in einer Krise die wahre Ursache zu übersehen.
Die Schritte, die ich in diesem Beitrag beschreibe, sind wie folgt:
- Definieren Sie das Problem
- Bestätigen Sie die aktuellen Bedingungen
- Antworten Sie „Ist es SQL Server“?
- CPU-Verbraucher identifizieren
- Passen Sie das Muster an und lösen Sie es
Dieser Artikel behandelt jeden dieser Schritte. Ich gehe davon aus, dass Sie möglicherweise kein Überwachungstool eines Drittanbieters verwenden. Wenn dies der Fall ist, gilt das Framework hier weiterhin, aber Ihre Datenquellen und Tools, die Ihnen zur Verfügung stehen, werden sich von dem unterscheiden, was ich beschreibe.
Definiere das Problem
Zuerst müssen wir das Problem eingrenzen. Wenn jemand auf Sie zukommt und sagt, dass er ein Problem mit der CPU-Leistung sieht, kann dies eine Reihe verschiedener Dinge bedeuten. Die erste Aufgabe besteht also darin, zu verstehen, was die Art des CPU-Leistungsproblems derzeit ist.
Einige gängige Kategorien sind:
- Verfügbarkeit aufgrund von „gebundenen CPUs“ beeinträchtigt. Zum Beispiel – alle Scheduler laufen durchgängig mit 100 % und der Durchsatz wird blockiert oder erheblich reduziert.
- Leistungseinbußen aufgrund von CPU-Auslastung, die „höher als normal“ ist. Wir sind also nicht gebunden, aber Ihre CPUs laufen mit einem höheren Prozentsatz als gewöhnlich, was sich vermutlich auf die Leistung auswirkt.
- Eine weitere häufige Kategorie von CPU-Leistungsproblemen ist das „Gewinner- und Verlierer“-Szenario, bei dem Workloads gegeneinander antreten. Möglicherweise haben Sie einen OLTP-Workload, der aufgrund einer parallel ausgeführten Berichtsabfrage auf einen reduzierten Durchsatz stößt.
- Ein weiteres Problem könnte das Erreichen eines Wendepunkts sein – wenn die Gesamtkapazität und die Skalierbarkeitsbeschränkungen Ihres Systems an einem bestimmten Punkt erreicht werden.
Ich erwähne diese übergreifenden Kategorien als Ausgangspunkt, aber ich weiß, dass es oft starke Abhängigkeiten zwischen diesen Themen geben kann und eine Kategorisierung in die andere übergehen kann. Vor diesem Hintergrund besteht der erste Schritt darin, die Symptome und Probleme so klar wie möglich zu definieren.
Bestätigen Sie die aktuellen Bedingungen
Unabhängig davon, ob das Problem in der Vergangenheit aufgetreten ist oder gerade auftritt, ist es wichtig, so viele Hintergrundinformationen wie möglich über das System, die Arbeitslast und die Konfigurationen zu erhalten. Wenn Sie Baselines und Runbooks verwenden, verfolgen Sie im Idealfall bereits viele dieser Informationen. Wenn nicht, fragen Sie sich, wie schnell Sie mitten in einer Krise um 2 Uhr morgens Antworten auf diese Fragen erhalten könnten.
Die folgenden Unterabschnitte behandeln wichtige Datenpunkte, an denen ich normalerweise bei Problemen mit der CPU-Leistung interessiert bin.
- Wie viele Sockel und Kerne?
- Ist Hyperthreading aktiviert?
- Was ist das Prozessormodell, die Architektur (32-Bit/64-Bit)?
- Ist das ein virtueller Gast?
- Wenn ja, interessieren Sie sich jetzt auch für Details über den Gastgeber und die anderen virtuellen Gäste, mit denen Sie Ressourcen teilen.
- Gibt es CPU-bezogene Einstellungen?
- Zum Beispiel Hyper-V-CPU
- Wie viele vCPUs werden Gästen zugewiesen?
- Wie viele vCPUs hat dieser Gast?
- Wurde der Gast vor dem Problem kürzlich zu einem neuen Host migriert?
- Einstellung des maximalen Parallelitätsgrades
- Kostenschwelle für Parallelitätsoption
- Einstellung der Prozessoraffinität
- Prioritätsverstärkungseinstellung
- Maximale Worker-Threads-Einstellung
- Leichte Pooling-Einstellung
- Was ist die Energieoptionseinstellung? (Betriebssystemebene, VM-Host oder BIOS-gesteuert)
- Hohe Leistung, ausbalanciert, stromsparend?
- Ist es über die Standardeinstellungen hinaus konfiguriert?
- Sehen Sie ungewöhnliche Warnungen oder Fehler?
Physische Serverdetails
Virtuelle Serverdetails
Reserve, VMware-CPU-Reservierung, Hyper-V-CPU-relative Gewichtung und VMware-CPU-Anteile.
Konfigurationseinstellungen der SQL Server-Instanz
Die ersten drei Konfigurationen erfordern möglicherweise weitere Diskussionen. Es gibt selten Absolute bezüglich dieser Einstellungen.
In Bezug auf die letzten drei Einstellungen, wie z. B. „Prioritätsverstärkung“, werde ich definitiv auf mehr Hintergrundinformationen und Verlauf drängen, wenn ich sehe, dass sie nicht auf den Standardwerten liegen.
CPU-Energieoptionseinstellungen
Energieoptionseinstellungen unter „Hohe Leistung“ sind immer noch sehr verbreitet und sollten für Server, die SQL Server-Instanzen hosten, nicht ignoriert werden.
Konfiguration der Ressourcenkontrolle
Ich finde immer noch, dass es selten ist, dass Kunden diese Funktion überhaupt verwenden, aber es ist einfach zu überprüfen, ob sie verwendet wird, und es wird sich für die Zeiten lohnen, in denen sie tatsächlich über den Standard hinaus konfiguriert ist.
SQL Server-Fehlerprotokoll und Windows-Ereignisprotokolle
Warum in den Fehler- und Ereignisprotokollen nach einem CPU-Problem suchen? Upstreamprobleme können manchmal nachgelagerte Leistungsprobleme in SQL Server verursachen. Sie möchten keine Zeit damit verschwenden, eine Abfrage zu optimieren oder einen neuen Index hinzuzufügen, wenn Ihr Upstream-Ursachenproblem ein Hardwarekomponenten-Verschlechterungsproblem ist.
Antworten Sie „Ist es SQL Server?“
Es klingt offensichtlich, wenn ich danach frage, aber Sie möchten wirklich nicht viel Zeit mit der Fehlerbehebung eines hohen CPU-Problems in SQL Server verbringen, wenn der Schuldige nicht wirklich SQL Server ist.
Nehmen Sie sich stattdessen einen kurzen Moment Zeit, um zu überprüfen, welcher Prozess die meiste CPU verbraucht. Es stehen mehrere Optionen zur Auswahl, darunter:
- Prozess:% Benutzerzeit (Benutzermodus)
- Prozess:% privilegierte Zeit (Kernel-Modus)
- Task-Manager
- Prozess-Explorer
- Neueste CPU-Informationen über sys.dm_os_ring_buffers oder die Systemzustandssitzung für die spezifischen SQL Server-Instanzen, die auf dem System ausgeführt werden
Wenn es sich um SQL Server handelt und Sie mehrere SQL Server-Instanzen zur Auswahl haben, stellen Sie sicher, dass Sie die richtige SQL Server-Instanz auf dem Host beheben. Dazu gibt es mehrere Möglichkeiten, einschließlich der Verwendung von SELECT SERVERPROPERTY('processid') um die PID abzurufen und sie dann dem Task-Manager oder Process Explorer zuzuordnen.
Wenn Sie bestätigt haben, dass es sich um SQL Server handelt, sehen Sie eine hohe Benutzerzeit oder privilegierte (Kernel-)Zeit? Auch dies kann über Process:% Privileged Time (sqlservr object) und auch Windows Task Manager oder Process Explorer bestätigt werden.
Obwohl Probleme mit hoher Kernelzeit selten sein sollten, erfordern sie dennoch andere Fehlerbehebungspfade als CPU-Probleme mit normaler Benutzerzeit. Einige mögliche Ursachen für eine hohe Kernel-Zeit sind fehlerhafte Filtertreiber (Antivirus, Verschlüsselungsdienste), veraltete oder fehlende Firmware-Updates und Treiber oder defekte I/O-Komponenten.
CPU-Verbraucher identifizieren
Sobald Sie validiert haben, welche SQL Server-Instanz die CPU-Auslastung der Benutzerzeit auf dem System antreibt, gibt es im Internet zahlreiche vorgefertigte Abfragebeispiele, die Sie verwenden könnten.
Nachfolgend finden Sie eine Liste von DMVs, die häufig in verschiedenen Formen während eines Leistungsproblems verwendet werden. Ich habe dies in einem Q&A-Format strukturiert, um zu verstehen, warum Sie darauf zugreifen möchten.
- sys.dm_exec_requests
- sys.dm_exec_sql_text
- sys.dm_exec_sessions
- sys.dm_exec_connections
- sys.dm_exec_query_plan
- sys.dm_os_waiting_tasks
- sys.dm_exec_query_stats
- Aggregiert nach total_worker_time
- Definiere Durchschnitte mit der Ausführungszahl
- Bei Ad-hoc-Workloads können Sie nach query_hash gruppieren
- Verwenden Sie plan_handle mit sys.dm_exec_query_plan, um den Plan abzurufen
- sys.dm_os_tasks
- Geordnet nach session_id, request_id
- sys.dm_exec_query_plan
- Schauen Sie sich Planbetreiber an – aber denken Sie daran, dass dies nur der geschätzte Plan ist
- sys.dm_exec_query_stats
- Filtern Sie total_elapsed_time kleiner als total_worker_time
- Beachten Sie jedoch, dass dies ein falsches Negativ für Blockierungsszenarien sein kann – in denen die Dauer aufgrund eines Wartens auf eine Ressource überhöht ist
Welche Anfragen werden gerade ausgeführt und wie ist ihr Status?
Was wird ausgeführt?
Woher kommt es?
Wie sieht der geschätzte Plan aus? (aber seien Sie vorsichtig, XML auf einem bereits CPU-eingeschränkten System zu schreddern)
Wer wartet auf eine Ressource und worauf warten sie?
Welche Abfragen haben seit dem letzten Neustart die meiste CPU-Zeit in Anspruch genommen?
Verwendet diese Abfrage Parallelität?
Passen Sie das Muster an und lösen Sie es
Sie lachen wahrscheinlich über diesen speziellen Schritt – da dieser der aufwändigste sein kann (und ein weiterer Grund ist, warum SQL Server-Profis erwerbstätig sind). Es gibt verschiedene Muster und damit verbundene Lösungen – daher beende ich diesen Beitrag mit einer Liste der häufigsten Treiber für CPU-Leistungsprobleme, die ich in den letzten Jahren gesehen habe:
- Hohe E/A-Operationen (und meiner Erfahrung nach ist dies der häufigste CPU-Treiber)
- Probleme bei der Kardinalitätsschätzung (und damit verbundene schlechte Qualität des Abfrageplans)
- Unerwartete Parallelität
- Exzessive Kompilierung/Neukompilierung
- Rechenintensive UDF-Aufrufe, Schredderoperationen
- Reihenweise quälende Reihenoperationen
- Gleichzeitige Wartungsaktivitäten (z. B. UPDATE-Statistiken mit FULLSCAN)
Jeder Bereich, den ich identifiziert habe, hat eine große damit verbundene Forschungsarbeit. Was die konsolidierten Ressourcen betrifft, denke ich, dass einer der besseren immer noch der technische Artikel „Troubleshooting Performance Problems in SQL Server 2008“ von Sunil Agarwal, Boris Baryshnikov, Keith Elmore, Juergen Thomas, Kun Cheng und Burzin Patel ist. P>
Zusammenfassung
Wie bei jeder Methodik gibt es Grenzen für ihre Verwendung und Bereiche, in denen Sie zum Improvisieren berechtigt sind. Bitte beachten Sie, dass ich nicht vorschlage, dass die in diesem Beitrag beschriebenen Schritte als starres Framework verwendet werden, sondern sie stattdessen als Ausgangspunkt für Ihre Bemühungen zur Fehlerbehebung betrachten. Selbst sehr erfahrene SQL Server-Experten können Anfängerfehler machen oder durch ihre neueren Erfahrungen mit der Fehlerbehebung voreingenommen sein, sodass eine minimale Methodik dazu beitragen kann, die Fehlerbehebung des falschen Problems zu vermeiden.
