MAXDOP und Cost Threshold for Parallelism

Standardwerte für Parallelität sind selten ein bewusstes Lastdesign. Zu viel Parallelität erhöht CPU- und Worker-Druck, zu starke Begrenzung verlangsamt analytische Arbeit.

Was gemessen werden sollte

Prüfen Sie CPU, ausführbare Tasks, Worker-Erschöpfung, Dauer, parallele Pläne, Exchange-Wartezeiten, NUMA und den Mix aus kurzen OLTP-Abfragen und Berichten.

Praktisches Vorgehen

Wählen Sie einen Ausgangswert für MAXDOP anhand von Topologie und Last, erhöhen Sie Cost Threshold schrittweise, messen Sie Tail Latency und Durchsatz und nutzen Sie Ausnahmen nur mit Nachweis.

Was vermieden werden sollte

Behandeln Sie CXPACKET nicht als Beweis, setzen Sie MAXDOP nicht global auf eins und ändern Sie nicht beide Werte ohne Baseline.

Betriebliches Ergebnis

Parallelität ist gut abgestimmt, wenn Durchsatz und Tail Latency gemeinsam besser werden, nicht wenn ein Wartetyp verschwindet.

Checkliste für die Produktion

Erfassen Sie eine Ausgangsbasis und definieren Sie die erwartete Verbesserung. Testen Sie mit repräsentativen Daten und realistischer Parallelität. Sichern Sie die ursprüngliche Einstellung oder den Plan, bereiten Sie einen Rollback vor und überwachen Sie die nächste normale Lastspitze.

Wenn Sie diese Methode auf eine konkrete SQL-Server-Umgebung anwenden möchten, nutzen Sie das Frageformular unten und nennen Sie SQL-Server-Version, Datenbankgröße, Lastprofil und bereits erfasste Nachweise.