Was zu tun (oder nicht zu tun) ist, wenn es um Top-Wartestatistiken geht

Einer der häufigsten Begriffe, der in Diskussionen über die Leistungsoptimierung von SQL Server auftaucht, ist Wartestatistiken . Dies reicht weit zurück, sogar vor diesem Microsoft-Dokument von 2006, „SQL Server 2005 Waits and Queues.“

Wartezeiten sind absolut nicht alles, und diese Methode ist nicht die einzige Möglichkeit, eine Instanz zu optimieren, ganz zu schweigen von einer einzelnen Abfrage. Tatsächlich sind Wartezeiten oft nutzlos, wenn Sie nur die Abfrage haben, die sie erlitten hat, und keinen umgebenden Kontext, besonders lange danach. Dies liegt daran, dass das, worauf eine Abfrage wartet, häufig nicht die Schuld dieser Abfrage ist . Wie bei allem gibt es Ausnahmen, aber wenn Sie ein Tool oder Skript nur auswählen, weil es diese sehr spezifische Funktionalität bietet, denke ich, dass Sie sich selbst einen schlechten Dienst erweisen. Ich neige dazu, einem Ratschlag zu folgen, den Paul Randal mir vor einiger Zeit gegeben hat:

Gelegentlich, ja, möchten Sie vielleicht tiefer in eine einzelne Abfrage eintauchen und sehen, worauf sie wartet; Tatsächlich hat Microsoft kürzlich Wartestatistiken auf Abfrageebene zu Showplan hinzugefügt, um bei dieser Analyse zu helfen. Aber diese Zahlen helfen Ihnen normalerweise nicht dabei, die Leistung Ihrer Instanz als Ganzes zu optimieren, es sei denn, sie helfen dabei, auf etwas hinzuweisen, das sich zufällig auch auf Ihre gesamte Arbeitslast auswirkt. Wenn Sie eine Abfrage von gestern sehen, die 5 Minuten lang lief, und feststellen, dass ihr Wartetyp LCK_M_S war , was willst du jetzt dagegen tun? Wie wollen Sie herausfinden, was die Abfrage tatsächlich blockiert und diesen Wartetyp verursacht hat? Es könnte durch eine Transaktion verursacht worden sein, die aus einem anderen Grund nicht festgeschrieben wurde, aber Sie können das nicht sehen, wenn Sie den Zustand des gesamten Systems nicht sehen können und sich nur auf einzelne Abfragen und die Wartezeiten konzentrieren, die sie erfahren haben.

Jason Hall (@SQLSaurus) erwähnte nebenbei etwas, das auch für mich interessant war. Er sagte, wenn Wartestatistiken auf Abfrageebene ein so wichtiger Teil der Optimierungsbemühungen gewesen wären, wäre diese Methodik von Anfang an in den Abfragespeicher integriert worden. Es wurde kürzlich hinzugefügt (in SQL Server 2017). Aber Sie erhalten immer noch keine Wartestatistiken pro Ausführung; Sie erhalten Durchschnittswerte über die Zeit, wie die Abfragestatistiken und Verfahrensstatistiken, die Sie in DMVs sehen. Daher können plötzliche Anomalien auf der Grundlage anderer Metriken erkennbar sein, die pro Abfrageausführung erfasst werden, aber nicht auf der Grundlage der Durchschnittswerte der Wartezeiten, die über alle gezogen werden Hinrichtungen. Sie können den Bereich, über den Wartezeiten aggregiert werden, anpassen, aber auf stark ausgelasteten Systemen ist dies möglicherweise immer noch nicht granular genug, um das zu tun, was Sie Ihrer Meinung nach für Sie tun werden.

Der Zweck dieses Beitrags ist es, einige der häufigsten Arten von Wartezeiten zu diskutieren, die wir in unserem Kundenstamm sehen, und welche Art von Maßnahmen Sie ergreifen können (und nicht sollten), wenn sie auftreten. Wir haben eine Datenbank mit anonymen Wartestatistiken, die wir seit geraumer Zeit von unseren Cloud Sync-Kunden sammeln, und seit Mai 2017 zeigen wir allen, wie diese in der SQLskills Waits Library aussehen.

Paul spricht über den Grund hinter der Bibliothek und auch über unsere Integration mit diesem kostenlosen Service. Grundsätzlich schlagen Sie einen Wartetyp nach, den Sie erleben oder auf den Sie neugierig sind, und er erklärt, was er bedeutet und was Sie dagegen tun können. Wir ergänzen diese qualitativen Informationen mit einem Diagramm, das zeigt, wie weit verbreitet die aktuelle Wartezeit in unserer Benutzerbasis ist, und vergleichen dies mit allen anderen Wartezeittypen, die wir sehen, sodass Sie schnell erkennen können, ob Sie es mit einem gemeinsamen Wartetyp oder etwas mehr zu tun haben exotisch. (Denken Sie daran, dass SQL Sentry nicht die gutartigen, Hintergrund- und Warteschlangenwartezeiten enthält, die zu Lärm führen und die die meisten Skripts da draußen herausfiltern, wie WAITFOR oder LAZYWRITER_SLEEP – dies sind einfach keine Ursachen für Leistungsprobleme.)

Hier ist ein Beispieldiagramm für CXPACKET , der häufigste Wartetyp da draußen:

Ich fing an, ein wenig weiter zu gehen, indem ich einige der häufigeren Wartetypen abbildete und einige der Eigenschaften notierte, die sie gemeinsam hatten. Übersetzt in Fragen, die ein Tuner möglicherweise zu einem Wartetyp hat, den er erlebt:

• Kann der Wartetyp auf Abfrageebene gelöst werden?
• Wirkt sich das Hauptsymptom des Wartens wahrscheinlich auf andere Abfragen aus?
• Benötigen Sie wahrscheinlich weitere Informationen außerhalb des Kontexts einer einzelnen Abfrage und der aufgetretenen Wartetypen, um das Problem zu "lösen"?

Als ich anfing, diesen Beitrag zu schreiben, war mein Ziel, die häufigsten Wartetypen zusammenzufassen und dann damit zu beginnen, Notizen über sie zu machen, die sich auf die oben genannten Fragen beziehen. Jason holte die gebräuchlichsten aus der Bibliothek, und dann zeichnete ich ein paar Hühnerkratzer auf ein Whiteboard, das ich später ein wenig aufräumte. Diese anfängliche Recherche führte zu einem Vortrag, den Jason auf der letzten TechOutbound SQL Cruise in Alaska hielt. Es ist mir irgendwie peinlich, dass er einen Vortrag zusammengestellt hat, Monate bevor ich diesen Beitrag beenden konnte, also machen wir einfach weiter. Hier sind die Top-Wartezeiten, die wir sehen (die weitgehend mit Pauls Umfrage aus dem Jahr 2014 übereinstimmen), meine Antworten auf die obigen Fragen und einige Kommentare dazu:

Zusammenfassung

In den meisten dieser Fälle ist es besser, Wartezeiten auf Instanzebene zu betrachten und sich nur auf Abfrageebene zu konzentrieren, wenn Sie bestimmte Abfragen beheben, die unabhängig vom Wartetyp Leistungsprobleme aufweisen. Dies sind Dinge, die aus anderen Gründen auftauchen, wie z. B. lange Dauer, hohe CPU-Leistung oder hohe E/A, und nicht durch einfachere Dinge erklärt werden können (z. B. ein Clustered-Index-Scan, wenn Sie eine Suche erwartet haben).

Jagen Sie auch auf Instanzebene nicht jedem Wait hinterher, der zum Top Wait auf Ihrem System wird – Sie werden es IMMER tun Haben Sie ein Top-Warte, und Sie werden nie aufhören können, es zu jagen. Stellen Sie sicher, dass Sie harmlose Wartezeiten ignorieren (Paul führt eine Liste) und sich nur Gedanken über Wartezeiten machen, die Sie mit einem tatsächlichen Leistungsproblem in Verbindung bringen können, das Sie erleben. Wenn CXPACKET Wartezeiten sind hoch, na und? Gibt es noch andere Symptome, abgesehen davon, dass diese Zahl "hoch" ist oder ganz oben auf der Liste steht?

Es kommt in erster Linie darauf an, warum Sie die Fehlerbehebung durchführen. Beschwert sich ein einzelner Benutzer über eine einzelne Instanz einer betrügerischen Abfrage? Ist Ihr Server auf den Knien? Etwas dazwischen? Im ersten Fall kann es natürlich nützlich sein, zu wissen, warum eine Abfrage langsam ist, aber es ist ziemlich teuer, alle Wartezeiten zu verfolgen (egal, auf unbestimmte Zeit aufzubewahren), den ganzen Tag, jeden Tag, wenn Sie die Gelegenheit dazu haben später wiederkommen und sie überprüfen möchten. Wenn es sich um ein allgegenwärtiges Problem handelt, das auf diese Abfrage isoliert ist, sollten Sie in der Lage sein, festzustellen, was diese Abfrage langsam macht, indem Sie sie erneut ausführen und den Ausführungsplan, die Kompilierungszeit und andere Laufzeitmetriken erfassen. Wenn es sich um eine einmalige Sache handelte, die letzten Dienstag passiert ist, können Sie das Problem möglicherweise nicht ohne mehr Kontext lösen, unabhängig davon, ob Sie die Wartezeiten für diese einzelne Instanz der Abfrage haben oder nicht. Vielleicht gab es eine Blockierung, aber Sie werden nicht wissen, wodurch, oder vielleicht gab es eine E/A-Spitze, aber Sie müssen dieses Problem separat aufspüren. Der Wait-Typ allein liefert normalerweise einfach nicht genug Informationen, außer bestenfalls einen Zeiger auf etwas anderes.

Natürlich muss ich auch hier meinen Unterhalt verdienen. Unser Flaggschiffprodukt, SQL Sentry, verfolgt einen ganzheitlichen Überwachungsansatz. Wir erfassen instanzweite Wartestatistiken, kategorisieren sie für Sie und stellen sie auf unserem Dashboard grafisch dar:

Sie können anpassen, wie jede einzelne Wartezeit kategorisiert wird und ob diese Kategorie überhaupt auf dem Dashboard angezeigt wird oder nicht. Sie können die aktuellen Wartestatistiken mit integrierten oder benutzerdefinierten Baselines vergleichen und sogar Warnungen oder Aktionen einrichten, wenn sie eine definierte Abweichung von der Baseline überschreiten. Und, was vielleicht am wichtigsten ist, Sie können sich einen Datenpunkt aus der Vergangenheit ansehen und das gesamte Dashboard mit diesem Zeitpunkt synchronisieren, sodass Sie den gesamten umgebenden Kontext und alle anderen Situationen erfassen können, die das Problem beeinflusst haben könnten. Wenn Sie granularere Dinge finden, auf die Sie sich konzentrieren müssen, wie Blockierung, hohe Festplattenlatenz oder Abfragen mit hohem I/O oder langer Dauer, können Sie diese Metriken genauer untersuchen und dem Problem ziemlich schnell auf den Grund gehen.

Weitere Informationen sowohl zu allgemeinen Ansätzen für Wartestatistiken als auch zu unserer Lösung im Besonderen finden Sie im Whitepaper von Kevin Kline, Troubleshooting SQL Server Wait Stats, und Sie können ein zweiteiliges Webinar herunterladen, das von Paul Randal, Andy Yun (@SQLBek) präsentiert wird. und Andy Mallon (@AMtwo):

• Teil 1:Fehlerbehebung bei der Leistung mithilfe von Wartestatistiken
• Teil 2:Schnelle Analyse der Wartestatistik mit SentryOne

Und wenn Sie die SentryOne-Plattform ausprobieren möchten, können Sie hier mit einem zeitlich begrenzten Angebot loslegen: