Kostenschwelle für Parallelität

Level – Fortgeschritten

Im SQL Server gibt es einen Konfigurationsparameter mit dem Namen „Kostenschwelle für Parallelität“. Standardmäßig ist er mit dem Wert 5 konfiguriert was aber nicht mehr zeitgemäß ist.

Aktuell kann man sagen, dass ein Wert zwischen 25 – 50 für OLTP Anwendungen angemessen ist. Leider kann man keine allgemein gültige Aussage treffen welcher Wert der Richtige ist. 

Aber welche Auswirkungen hat nun dieser Wert für die Abarbeitung von Abfragen?

Innerhalb des Ausführungsplans gibt es Operatoren welche parallel ausgeführt werden können. Die Entscheidung ob die Operation nun parallel ausgeführt wird oder nicht, richtet sich nach den berechneten Kosten dafür. Liegen die berechneten Kosten höher als der konfigurierte Wert wird der Vorgang parallelisiert, wenn er kleiner ist dann wird nur auf einem Core berechnet.

Demo

Um dieses Verhalten zu demonstrieren braucht man zunächst eine Datenbank mit einer großen Tabelle und einer Abfrage welche parallelisierbar ist.

Als Datenbank verwende ich die AdventureWorksDW2012 von Microsoft und eine Abfrage mit einem ORDER BY als parallelisierbarer Vorgang. Um die Unterschiede deutlich zu machen sehen wir uns jeweils die Ausführungspläne bei den verschiedenen Varianten an.

parallel

Startkonfiguration des SQL Server

Zu Beginn setzten wir die Kostenschwelle auf 75 und führen die Abfrage aus.

SELECT * FROM FactProductInventory
ORDER BY MovementDate
parallel0
Ausführungsplan ohne parallele Ausführung

Da der SORT Operator hier Kosten von etwa 74 hat, wird keine Parallelisierung durchgeführt.

parallel2
Korrektur der Kostenschwelle um -1 

Nun setzten wir die Kostenschwelle auf 74 und führen die Abfrage erneut aus.

parallel3
Ausführungsplan mit paralleler Ausführung des Sort Operators

Da nun die geschätzten Kosten über dem Wert der Kostenschwelle liegen, wird nun der SORT Operator als paralleler Task durchgeführt wird.

Schlussfolgerung

Der Wert für die Kostenschwelle sollte mit bedacht gewählt werden. Ist dieser Wert zu klein wird der SQL Server sehr früh (eventuell zu früh) beginnen Abfragen zu parallelisieren. Dies hätte zur Folge, dass kleine Abfragen länger warten müssen da sie vermehrt auf CPU Zuteilungen warten müssen, da größere Abfragen mehrere Cores gleichzeitig belegen. Ist der Wert zu hoch gewählt, dauern die größeren Abfragen länger obwohl eventuell weitere Cores frei wären um die Abarbeitungszeit zu beschleunigen.

Advertisements

2 Gedanken zu “Kostenschwelle für Parallelität

    • Benjamin Hoch 21. November 2016 / 9:23

      Die Beurteilung ist sehr schwierig. Das Problem ist halt dass man den kompletten Prozess über die gesamte Laufzeit bewerten muss. Man kann sich für die Replay Funktion alle Abfragen für einen Zeitraum aufzeichnen und auf ein Testsystem übertragen. Dort kann man dann die verschiedenen Werte mit identischer Arbeitslast laufen lassen und sehen wie sich das Gesamtverhalten verändert.

      Gefällt mir

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s