Hat sich die Anleitung zur Einstellung der Kostenschwelle für Parallelität mit dem Aufkommen von Columnstore-Indizes geändert?

Zunächst einmal, was ich nicht frage. Ich frage nicht, wie meine Einstellung sein soll.

Viele empfehlen, den Wert über den Standardwert hinaus zu erhöhen, und ich verstehe mit Sicherheit, warum dies bei B-Tree-basierten Abfragen der Fall ist. Ich habe jedoch über die (fast) lineare Skalierbarkeit von In-Memory-Clustered-Columnstore-Indizes gelesen und frage mich, ob ein zu hoher Kostenschwellenwert dazu führen kann, dass SQL Server spaltenbasierte Abfragen für CPU-Kerne aushungert.

Die Frage lautet also: Behandelt SQL Server Columnstore-Indizes anders, wenn es um die 'Kostenschwelle für Parallelität' geht, und sollte dies dazu führen, dass ich meine Entscheidung über meine anfängliche Einstellung ändere?

Über die Einstellung für den Kostenschwellenwert hinaus scheint SQL Server die Parallelität für Spaltenspeicherindizes je nach Ihrer SQL Server-Version (2012 gegenüber 2014) und sogar den Datentypen in Ihrer Tabelle unterschiedlich zu behandeln.

Ich würde mit Joe Changs Post-Benchmarking von Dezimal- und Float-Datentypen beginnen und auch die Kommentare zu diesem Post lesen. Wenn Sie genau die richtigen MAXDOP- und Kostenschwellenwerte für Parallelität für Ihr System erhalten möchten, müssen Sie die detaillierten Tests durchführen, die Joe in seinem Beitrag durchführt, und das erfordert viel Arbeit. Aus diesem Grund würde ich mich zuerst auf den primären Engpass Ihres Systems konzentrieren - verwenden Sie Wartestatistiken, um sicherzustellen, dass Parallelität oder CPU-Druck Probleme für Sie sind, und optimieren Sie dann zunächst die CPU-intensivsten Abfragen, anstatt Änderungen an den Systemeinstellungen vorzunehmen.

TL; DR: Die vorgeschlagene Anfangseinstellung von 50, über die Sie gelesen haben, bleibt ein guter Ausgangspunkt. MAXDOP von 1 physischen Kern pro NUMA-Knoten ist eine gute Einstellung für einen Server wie unseren, der sowohl OLTP- als auch OLAP-Workloads bedient.

Corrolary: SQL Server ist wirklich sehr, sehr gut darin, was es tut.

Meine Hauptsorge bei dieser Einstellung war, ob ich die parallele Ausführung auf einem Clustered-Columnstore-basierten Index für ziemlich kurze Abfragen verhindern würde oder nicht. Würde eine Einstellung von 50 dazu führen, dass eine Abfrage unter 1 Sekunde viel länger dauert? Würde die Einstellung "Kostenschwelle für Parallelität" einfach ignoriert, da Columnstore-Indizes mit CPUs so gut skaliert werden können?

• F: Wird SQL Server überhaupt die Kostenschwelle für Parallelität für Columnstore-Indizes einhalten?

• A: Ja. Bei einer Konfiguration mit einer lächerlichen Einstellung von 30.000 wurde die Parallelität für Columnstore-Indizes für meine Workloads effektiv deaktiviert. Das Ausprobieren anderer, immer noch obszöner Werte (1.500) verhinderte die Parallelität von Workloads, deren Ausführung nominell etwa eine Sekunde dauerte, aber Abfragen, die nominell in etwa 10 oder mehr Sekunden ausgeführt wurden, zeigten parallele Ausführungspläne.

• F: Ist eine Standardeinstellung von 50, wie in einigen Checklisten angegeben, ein sicherer Wert, der die Parallelität für meine auf Spaltenspeichern basierenden Abfragen nicht verhindert?

• A: Ja , und bei weitem nicht. Selbst wenn der Wert auf 500 erhöht wurde, war die Parallelität für einfache, kurze (unter einer Sekunde) Spaltenspeicher-basierte Abfragen möglich.

Über meinen Server, meine Arbeitslast und meine Ergebnisse:

• 2x Xeon E2650v2 (2 NUMA-Knoten, 12 physische Kerne, 24 HT-Threads), 384 GB RAM
• MAXDOP konfiguriert auf 6 (6 physische Kerne pro NUMA-Knoten)
• SQL Server 2014 Enterprise CU4
• Testen auf 111.000.000 Zeilenclustered Columnstore-Index in 6 Partitionen (pro Jahr)

Zwei getestete Workloads:

• SELECT COUNT(DISTINCT <low cardinality column>) FROM table;

• SELECT COUNT(DISTINCT <high cardinality column>) FROM table;

Die Abfrage der Spalte mit hoher Kardinalität dauerte 84 Sekunden (verstrichen) bei Schwellenwerten über 1500 und etwa 14 Sekunden (verstrichen) bei Schwellenwerten unter dieser Zahl. Die Abfrage der Spalte mit niedriger Kardinalität dauerte etwa 250 ms (verstrichen) bei Schwellenwerten von 500 und darunter und 18 (verstrichene) Sekunden bei Schwellenwerten über 1500. (Ich habe nicht versucht, den genauen Punkt zu messen, an dem die Pläne gewechselt wurden.) Interessanterweise Wenn die Parallelität gesperrt ist, steigt die Gesamt-CPU-Zeit für die Abfrage mit niedriger Kardinalität dramatisch an. Möglicherweise verwendet der Server den Stapelmodus für diese Abfrage nicht mehr.

Heh, letztendlich führt das Ausführen von Tests zu mehr Fragen, aber das ist alles Blog-Futter und geht über den Rahmen dieser Frage hinaus.

Ich möchte dem Artikel von Joe Chang hinzufügen, dass Sie diesen Artikel von Paul White lesen sollten , in dem er ein Trace-Flag behandelt, das CTFP für die von Ihnen ausgeführte Abfrage im Wesentlichen auf 0 setzt. Ich weiß, dass es nicht genau das ist , wonach Sie suchen, aber zusammen mit MAXDOP-Tests können Sie eine gute Vorstellung davon bekommen, ob Ihre parallele Abfrage überhaupt für Spaltenspeicher-Indexe von Vorteil ist. Ich habe es in letzter Zeit ein wenig ausprobiert (ich schwöre bei dev), anstatt den Plan, Parallelität zu erzwingen, künstlich zu komplizieren.