Wenn sich Ihre Datenbankbenutzer darüber beschwert haben, dass die Leistung von SQL Server in letzter Zeit mangelhaft war, ist es möglich, dass Sie die Auswirkungen eines oder mehrerer SQL Server-Engpässe erleben. Diese Engpässe treten aus einer Vielzahl von Gründen auf, treten jedoch häufig als Folge von Problemen mit Speicher, E/A oder CPU auf.
Obwohl es nicht immer einfach ist festzustellen, ob Leistungsprobleme auf einen SQL Server-Engpass oder auf eine andere Quelle zurückzuführen sind, können Sie nach diesen häufigen Symptomen von Engpässen suchen, um Ihre Suche nach der Ursache des Problems einzugrenzen.
Häufige Symptome von SQL Server-Engpässen
- SQL Server belastet den Prozessor
- Längere Ausführungszeiten für Abfragen
- Übermäßige E/A
- Anwendungsprotokoll mit Meldungen wegen unzureichendem Arbeitsspeicher
- Extreme Aktivität auf den Festplatten
- Lange Wartezeiten pro I/O
Das plötzliche Auftreten eines oder mehrerer dieser Symptome ist ein guter Hinweis darauf, dass irgendwo in Ihrem System ein SQL Server-Engpass vorliegt. Jetzt ist es Ihre Aufgabe, es zu finden.
Arten von SQL Server-Engpässen
Es gibt drei Haupttypen von SQL Server-Engpässen:Arbeitsspeicher, E/A und CPU. Es ist wichtig, dass DBAs mit den Ursachen, Symptomen und Behebungen der einzelnen Probleme vertraut sind, damit sie die Engpässe schnell identifizieren und beseitigen und die Auswirkungen einer schlechten Leistung minimieren können. Wir haben auch einige der besten zu überwachenden Leistungsindikatoren aufgenommen, die dabei helfen, Leistungsengpässe sofort zu erkennen.
Speicherengpässe
Speicherengpässe sind in der Regel auf unzureichende Speicherressourcen oder SQL Server-Aktivitäten zurückzuführen, die verfügbaren Speicher belegen. Zu den Symptomen, auf die Sie achten sollten, gehören längere Abfrageausführungszeiten, übermäßige E/A, Meldungen zu wenig Arbeitsspeicher im Anwendungsprotokoll und häufige Systemabstürze.
Die beste Möglichkeit, speicherbezogene Engpässe zu vermeiden, besteht darin, einen Abfrageoptimierer zu verwenden, um unnötige oder veraltete Abfragen loszuwerden, und die Seitenlebenserwartung in Verbindung mit der Puffercache-Trefferquote zu konfigurieren, um Fahrten auf die Festplatte zu begrenzen. Wenn es zu spät ist, den Engpass zu vermeiden, versuchen Sie, Abfragen zu überprüfen und zu optimieren, Speicher neu zu konfigurieren oder physischen Speicher hinzuzufügen.
Zu überwachende Zähler:verfügbarer Speicher, Gesamtspeicher des Servers, Speicher des Zielservers, Seiten/Sek., Puffer-Cache-Trefferquote
E/A-Engpässe
Wenn nicht genügend Speicher verfügbar ist, um reguläre Datenbankoperationen wie TempDB zu unterstützen, treten wahrscheinlich E/A-Engpässe auf. Lange Antwortzeiten, Anwendungsverlangsamungen und häufige Zeitüberschreitungen bei Aufgaben sind Schlüsselindikatoren für einen E/A-Engpass.
Sie können diese Art von Engpässen vermeiden, indem Sie eine Überwachung mit Alarmen und Schwellenwertwarnungen einrichten, um zu ermitteln, welche Aktivitäten übermäßig viel Speicherplatz beanspruchen. Wenn ein E/A-Engpass auftritt, beschränken Sie das Lesen und Schreiben von Datenbankseiten auf und von der Festplatte. Dazu müssen Sie nach häufigen Index-Scans, ineffizienten Abfragen und veralteten Statistiken suchen und diese korrigieren.
Zu überwachende Leistungsindikatoren:durchschnittliche Festplattenwarteschlangenlänge, durchschnittliche Festplatten-Sek./Lesevorgänge, durchschnittliche Festplatten-Sek./Schreibvorgänge, % Festplattenzeit, durchschnittliche Festplatten-Lesevorgänge/Sek., durchschnittliche Festplatten-Schreibvorgänge/Sek.
CPU-Engpässe
Die Hauptursache für CPU-Engpässe sind unzureichende Hardwareressourcen. Es ist ziemlich einfach, diesen Engpass zu identifizieren, indem Sie Ihre Protokolle überprüfen, um festzustellen, ob SQL Server übermäßig viel CPU verwendet.
In einer idealen Welt könnten Sie CPU-Engpässe vermeiden, indem Sie einen dedizierten Nur-SQL-Server-Server haben und die gesamte andere Software auf einem anderen Computer ausführen. Da dies für die meisten DBAs keine Option ist, müssen Sie wissen, wie Sie Ihre CPU entlasten können.
Der erste Schritt besteht darin, die CPU-Hogs zu identifizieren. Sobald Sie wissen, wo das Problem liegt, können Sie Abfragen optimieren, Ihre Ausführungspläne verbessern oder das System neu konfigurieren.
Zu überwachende Zähler:% Prozessorzeit, Batch-Anforderungen/Sek., SQL-Kompilierungen/Sek., SQL-Neukompilierungen/Sek.
Eine Geschichte über Leistungsengpässe bei SQL Server
„Wir haben einige Leistungsengpässe bei SQL Server zu bewältigen“, sagte mein Chef an einem späten Freitag.
"Woher weißt du das?" fragte ich.
„Der Vertrieb beschwert sich darüber, dass seine Datenbank in letzter Zeit langsamer geworden ist. Wir müssen sehen, was damit los ist.“
"OK. Ich buche einen Konferenzraum, damit wir uns zusammensetzen und daran arbeiten können.“
„Keine Sorge“, sagte der Chef. „Es ist später Freitagnachmittag. Das bedeutet, dass Engpässe am besten mit ein paar eigenen untersucht werden können. Wir gehen zum Pike Pub auf dem Markt.“
Wir gingen in eine versteckte Bar am Pike Place Market und fanden einen kleinen Tisch am Fenster.
„Was ist Ihre Lieblingsart von Engpässen?“ fragte der Chef.
Ich sagte, ich hätte eine Vorliebe für eine Naughty Nellie im 22-Unzen-Flaschenhals.
„Gute Wahl“, sagte der Chef. „Du bestellst das und ich nehme das Citrus Summer Ale.“
Während wir auf unsere Engpässe warteten, machten wir uns an die Leistungsengpässe von SQL Server.
„Wir müssen an mehreren Stellen nach Problemen suchen“, sagte der Chef. „Es könnten Probleme mit dem Speicher, der Speicherung oder den Prozessoren sein, aber für die Benutzer sehen sie alle ungefähr gleich aus, oder? Schlechte Leistung.
„CPU-Probleme sind nicht so schwer zu finden. Wenn dies das Problem ist, werden wir sehen, dass SQL Server den Prozessor in Beschlag nimmt und dafür sorgt, dass er die ganze Zeit über ansteigt.
„Wenn es sich um ein Speicherproblem handelt, sehen wir Dinge wie längere Ausführungszeiten bei den Abfragen und mehr E/A, da die Anwendung weiterhin auf der Festplatte ausgeführt werden muss. Wir können auch das Anwendungsprotokoll auf Meldungen über unzureichenden Arbeitsspeicher prüfen.
„Und wenn der Engpass im Speicher liegt, sehen wir extreme Aktivität auf den Festplatten und lange Wartezeiten pro I/O.“
Unsere Engpässe sind angekommen. Wir haben sie sorgfältig studiert, als wir uns eingehender mit dem Leistungsproblem beschäftigten.
Die vielen potenziellen Quellen für Leistungsengpässe bei SQL Server
„Was ist, wenn es sich um ein E/A-Problem handelt?“ Ich habe gefragt. „Wir sollten sehen, ob die WRITELOG-Wartezeit im Vergleich zur Gesamtwartezeit zu hoch ist. Oder, wo wir gerade von E/A sprechen, vielleicht gibt es ein Problem in der SQL selbst. Wenn es ineffizienten Code gibt, wie z. B. einen NESTED LOOP JOIN in einer riesigen Tabelle, könnte die SQL zigmal nachfragen, ob Zeilen in der inneren Tabelle gelesen werden sollen. Das würde die Leistung wirklich bestrafen.“
„Könnte sein“, sagte der Chef. „Komplexe Verknüpfungen und Sortiervorgänge können schwierig sein, insbesondere wenn die tempdb-Datenbank nicht richtig konfiguriert ist. Tempdb-Konkurrenz sieht aus wie gewöhnliche Datenbanksperren, ist aber eigentlich eine verriegelte Konkurrenz, weil gleichzeitige Prozesse alle darauf warten, auf den Zuordnungsseiten an die Reihe zu kommen.“
„Mit welchen Werkzeugen können wir all diese Dinge untersuchen?“ fragte ich.
„SQL Server hatte einen Profiler zum Untersuchen gespeicherter Prozeduren, aber er ist veraltet. So etwas ist eine gute Möglichkeit, Problemabfragen zu finden und zu diagnostizieren, auch wenn es nur der erste Schritt ist. Dann gibt es dynamische Verwaltungsansichten und -funktionen, die Ihnen helfen, den Zustand Ihres Servers und Ihrer Datenbank zu überwachen, Probleme zu beseitigen und Ihr SQL zu optimieren.“
„Aber SQL Server hat so viele bewegliche Teile“, sagte ich. „Ich hätte lieber ein Tool, das das Gesamtbild von außen nach innen betrachtet.“
„Das würde ich auch tun. Vorzugsweise aus der Cloud, damit wir dafür keine weitere Hardware und Software vor Ort benötigen.“
Beseitigung von Leistungsengpässen in SQL Server
Pike begann, voll zu werden. Und so gerne der Chef und ich in einer Kneipe saßen und fachsimpelten, es war immerhin Freitagabend. Wir hatten andere Orte zu besuchen, andere Leute zu sehen und andere Dinge zu besprechen.
„Was sollen wir tun, wenn wir die Engpässe gefunden haben?“ fragte ich.
„Wir schnappen die üblichen Verdächtigen“, sagte der Chef. „Um nicht zu viel Speicher zu verwenden, müssen wir den Datenbankentwicklern mitteilen, bei welchen ihrer Codes und Abfragen Speicherverluste auftreten. Wenn wir Operationen finden, die vier, fünf oder sechs Tabellen verbinden, müssen wir den Entwicklern einige SQL Server-Tuning-Tipps und Best Practices geben, um die Datenbank neu zu gestalten. Oder wir haben zu viele Indizes und verschwenden möglicherweise Zyklen, um sie zu aktualisieren. Das ist für die CPU und die E/A genauso hart wie zu wenige Indizes. Möglicherweise haben wir ein Problem mit der Indexfragmentierung von SQL Server oder wir müssen die veralteten und doppelten Indizes aussortieren.“
„Macht Sinn“, sagte ich. „Vielleicht müssen wir mehr Hardware darauf werfen. Schnellere Festplatten können bei I/O-Engpässen helfen. Mehr und schnellere CPUs wirken sich auf die Antwortzeiten von Abfragen aus. Und das Hinzufügen von RAM bedeutet mehr SQL Server-Skalierbarkeit, richtig?“
„Ja“, sagte der Chef, „aber zuerst möchte ich sicher sein, dass die Ursache kein Entwicklungs- oder DevOps-Problem ist. Sobald ich davon überzeugt bin, dass dies nicht der Fall ist, spiele ich die „Buy More Hardware“-Karte.“
Wir saßen einen Moment da und sahen zu, wie sich der Pub mit Nachtschwärmern am Freitagabend füllte.
„Boss“, fragte ich, „glaubst du, all diese Leute wissen, wie sorglos sie alle leben, ohne die Last, sich mit blockierten Sitzungen, maximalen I/O-Wartezeiten, Seitenlebensdauer und Buffer-Cache-Trefferquoten herumschlagen zu müssen?“
„Es ist ein Kreuz zu tragen, nicht wahr?“ antwortete der Chef. „Die meisten Menschen haben keine Ahnung, was wir durchmachen. Gut, dass wir Leistungsengpässe bei SQL Server so ruhig, mit so viel Anmut unter Druck und mit so gutem Geschmack behandeln. Apropos guter Geschmack, wie geht es dir mit deinem Flaschenhals?“
Ich überprüfte. „Mein Flaschenhals ist leer. Meine Flasche auch.“
"Meine auch. Zeit zu gehen. Wir müssen arbeiten.“
Ist ein Zero-SQL-Server-Flaschenhalssystem möglich?
Wir wissen, dass wir Maßnahmen ergreifen können, um diese drei häufigen Arten von SQL Server-Engpässen zu vermeiden. Aber ist es möglich, eine SQL Server-Datenbank so gut zu konfigurieren, dass sie keine Engpässe hat?
Die kurze Antwort ist wahrscheinlich nicht. Selbst beim fleißigsten DBA treten hin und wieder SQL Server-Engpässe auf. Sie können jedoch Maßnahmen ergreifen, um Engpässe proaktiv zu vermeiden und ihre Auswirkungen auf die Leistung zu minimieren. Beispielsweise bietet Brent Ozar einige großartige Tipps zur Überwachung von Perfmon-Zählern, um Ihren SQL Server zu optimieren, und Sie können die Ansicht sys.dm_os_performance_counters verwenden, um Engpässe zu erkennen und schnell zu beheben.
SQL Server-Engpässe gehören zum Alltag von DBAs. Glücklicherweise können Leistungsprobleme mit angemessener Aufsicht, sorgfältiger Überwachung und häufiger Abfrageoptimierung behoben werden, bevor Benutzer überhaupt bemerken, dass ein Problem vorliegt.
