MAXDOP and Cost Threshold for Parallelism

Default parallelism settings are rarely an intentional workload design. Excessive parallelism can amplify CPU and worker pressure, while restrictive settings can slow analytical work.

What to measure

Review CPU, runnable tasks, worker exhaustion, duration, parallel plan frequency, exchange waits, NUMA layout, and the mix of short OLTP queries and larger reports.

Practical approach

Use topology and workload guidance to select a starting MAXDOP, raise cost threshold gradually, measure tail latency and throughput, and apply database or query overrides only to demonstrated exceptions.

What to avoid

Do not treat CXPACKET as proof of a problem, set MAXDOP to one globally, or change both settings without a baseline.

Operational result

Parallelism tuning succeeds when throughput and tail latency improve together, not when one wait type disappears.

Production checklist

Capture a baseline and define the expected improvement. Test with representative data and concurrency. Preserve the original setting or plan, prepare a rollback, deploy during an appropriate window, and monitor the next normal workload peak.

If you want help applying this method to a specific SQL Server environment, use the question form below and include the SQL Server version, database size, workload pattern, and evidence already collected.