Brent Ozar, Microsoft Certified Master, hat kürzlich in seiner letzten Ausgabe der Herbstreihe der Database Training Days von Quest die Parallelität in SQL Server erörtert, insbesondere die Wartetypen CXPACKET und CXCONSUMER. Auf seine übliche humorvolle und zugängliche Weise entmystifizierte Brent die Konzepte der Parallelität und erklärte, wie man damit umgeht, wenn man zu viele CXPACKET- und CXCONSUMER-Wartestatistiken sieht.
Erstens, was ist Parallelität und warum führt SQL Server Abfragen parallel aus?
Einfach ausgedrückt, SQL Server erkennt automatisch, dass eine bestimmte Abfrage eine große Arbeitslast hat, und stellt fest, dass die Arbeit effizienter von mehreren Prozessoren als von nur einem Prozessor erledigt werden kann. Dies ist im Allgemeinen eine kluge Entscheidung, kann jedoch zu Problemen führen, wenn SQL Server die Last nicht auf die Threads verteilt, die die Aufgabe ausführen.
CXPACKET- und CXCONSUMER-Wartetypen verstehen
CXPACKET und CXCONSUMER sind Wartetypen, die darauf hinweisen, dass die Arbeit nicht gleichmäßig verteilt ist. Wenn Sie diese Wartestatistiken auf Ihrem Server sehen, wissen Sie, dass SQL Server Abfragen parallel ausführt, diese aber nicht besonders gut auf die verfügbaren Prozessoren verteilt.
Jeder Datenbankprofi ist mit dem Begriff „Kosten“ vertraut, um auszudrücken, wie teuer die Ausführung einer Abfrage in Bezug auf den Ressourcenverbrauch ist. Diese „Abfrage-Bucks“ sind ein ungefähres Maß für die Arbeit und ein wichtiges Signal dafür, ob die Abfrage parallel läuft oder nicht. Eine kostengünstige Abfrage muss nicht parallel laufen, eine teure hingegen schon. Das Ziel besteht darin, die Abfrage so schnell und effizient wie möglich auszuführen, damit die nächste in der Reihe beginnen kann. SQL Server bezeichnet einen Thread als Planer, und dieser Thread, den Brent als „Roboteroberherr“ bezeichnete, weist Teile der parallelen Arbeitslast den Worker-Threads oder den „Roboterminions“ zu.
Parallelismus und der Roboter-Overlord
Brent tauchte in eine Demo ein, um zu zeigen, wie das funktioniert. Unter Verwendung der Stack Overflow-Datenbank erstellte er eine kostengünstige Datenbanksuche, die aufgrund des Vorhandenseins eines Index sehr schnell war. Der Ausführungsplan war ziemlich unkompliziert und erforderte keine Parallelität zur Ausführung.
Aber als er eine Suche nach etwas einführte, das nicht im Index enthalten war, änderten sich die Dinge, indem er eine Schlüsselsuche für jede Zeile im gruppierten Index der Tabelle erzwang. SQL Server erkannte, dass dies eine Menge Arbeit bedeuten würde, führte also Parallelität ein und zeigte dies mit einem Symbol im Ausführungsplan an. Wenn der Ausführungsplan dreidimensional wäre, könnten Sie die mehreren gestapelten Threads sehen, aber da dies nicht der Fall ist, müssen Sie die Statistiken anzeigen, um Informationen wie die logischen Lesevorgänge zu sehen, die von jedem CPU-Thread ausgeführt werden.
Allerdings hat SQL Server diese Aufgabe nur einigen Threads zugewiesen, nicht allen. Brent erklärte, dass alles, was jenseits des parallelen Symbols passiert, nur auf den zugewiesenen Prozessoren passiert. Die Threads, die die ersten Lesevorgänge durchgeführt haben, sind jetzt also die einzigen, die auch die Schlüsselsuchen durchführen. Der Roboter-Overlord hat nur ein paar Schergen gebeten, die gesamte Aufgabe zu erledigen, anstatt alle Schergen zu bitten, mitzuhelfen.
Er erklärte weiter, dass SQL Server die Vorgänge der Threads berücksichtigen und verfolgen muss, was der Roboter-Overlord tut. In den frühen Tagen wurde all diese Arbeit durch eine Wartestatistik dargestellt, aber das machte keinen Sinn, denn egal was passiert, der Overlord muss immer noch warten, während alle Threads arbeiten. Daher wurde ein neuer Wartetyp eingeführt – das war CXCONSUMER und er verfolgt, was der Scheduler/Overlord-Thread tut, während CXPACKET verfolgt, was die Worker/Minion-Threads tun.
Brent kehrte zur Abfrage zurück, um sie noch komplexer zu machen, indem er eine Sortierung hinzufügte. Jetzt wird noch deutlicher, dass Parallelität ein Problem verursacht, anstatt den Betrieb effizienter zu machen. Die Arbeit ist über die wenigen Worker-Threads hinweg noch unausgeglichener geworden, und einigen geht der Arbeitsspeicher aus und sie werden auf die Festplatte übertragen. Er fügte einen Join hinzu, was die arbeitenden Kerne noch weiter belastet, die keine Unterstützung von den nicht arbeitenden Kernen erhalten. Die CXPACKET-Statistiken stiegen weiter an.
Was können Sie in dieser Situation tun? Die Parallelitätsentscheidung erfolgt auf Serverebene und nicht auf Abfrageebene, daher sind einige Konfigurationsänderungen erforderlich.
Schlüsselkonfigurationen bewerten
Wir haben bereits gelernt, dass SQL Server parallelisiert wird, wenn die Abfragekosten höher als ein bestimmtes Niveau sind. Kleine Abfragen werden auf einen einzelnen Thread beschränkt. Aber was steuert die Schwelle? Es ist eine Eigenschaft namens Cost Threshold for Parallelism (CTFP). Wenn der Ausführungsplan feststellt, dass die Kosten höher als 5 Abfragebucks sind, wird die Abfrage standardmäßig parallelisiert. Es gibt zwar keine Anleitung, wie dies einzustellen ist, aber Brent empfiehlt eine Zahl größer als 50. Dadurch wird die Parallelität für triviale Abfragen beseitigt.
Eine weitere Konfiguration ist der maximale Parallelitätsgrad (MAXDOP), der die Anzahl der Threads beschreibt, die SQL Server der Abfrage zuweist. Der Standardwert hier ist Null, was bedeutet, dass SQL Server alle verfügbaren Prozessoren, bis zu 64, verwenden kann, um die Abfrage auszuführen. Wenn Sie die Option MAXDOP auf 1 setzen, beschränkt sich SQL Server darauf, nur einen Prozessor zu verwenden, wodurch ein serieller Plan zur Ausführung der Abfrage erzwungen wird. SQL Server empfiehlt einen MAXDOP-Wert basierend auf der Anzahl Ihrer Serverkerne, aber im Allgemeinen ist ein niedrigerer MAXDOP-Wert sinnvoll, da nicht oft alle Kerne benötigt werden.
Brent nahm Anpassungen an diesen beiden Konfigurationen vor und führte seine Abfrage erneut aus. Diesmal konnten wir sehen, dass mehr Kerne am Parallelbetrieb beteiligt waren. Die CXPACKET-Wartestatistiken waren niedriger, was bedeutete, dass die Last gleichmäßiger auf mehr Kerne als zuvor verteilt war.
Tipps zur Bekämpfung von CXPACKET- und CXCONSUMER-Wartestatistiken
Brent empfiehlt die folgenden Schritte, wenn Sie übermäßige CXPACKET- und CXCONSUMER-Wartestatistiken sehen:
- Stellen Sie CTFP und MAXDOP gemäß den Best Practices der Branche ein und lassen Sie diese Einstellungen dann einige Tage lang backen. Dadurch wird der Plan-Cache geleert und SQL Server gezwungen, Abfrageausführungspläne neu zu erstellen (Kosten neu zu bewerten).
- Nehmen Sie Indexverbesserungen vor, die die Zeiten verkürzen, in denen Abfragen parallel ausgeführt werden, um Scans und Sortierungen durchzuführen. Lassen Sie neue Indizes backen und suchen Sie dann nach Abfragen, die noch viel Arbeit erledigen.
- Optimieren Sie diese Abfragen und lassen Sie sie ein paar Tage backen.
- Falls die Parallelität immer noch ein ernsthaftes Problem darstellt, beginnen Sie mit der Suche nach den spezifischen Abfragen mit Parallelitätsproblemen.
Für noch mehr Einblicke können Sie unten Brents gesamte Schulungssitzung zu CXPACKET- und CXCONSUMER-Wartestatistiken abrufen.
