0

We would like to implement best practice on our SQL Server instances. All of our instances still run with the default setting of MAXDOP = 0.

Having read several pages on the recommended settings for this (including Microsoft Support and Erik Darling's posts on brentozar.com), we wanted to check that we have understood these recommendations correctly in terms of our instances. All of our instances are running on virtual machines, and many have only one socket and only a handful of virtual processors.

Example 1:

  • 1 x socket 2.30 GHz
  • 6 x virtual processors
  • Running 1 x SQL Server instance (2016 SP1 CU8, Web Edition 64-bit)

Change MAXDOP from 0 to 6, or from 0 to 3?

Since this instance only has a single socket anyway, a change from 0 to 6 will surely make no difference? Are we likely to gain anything from changing this setting?

Example 2:

  • 2 x socket 2.30 GHz
  • 6 x virtual processors per socket
  • Running 8 x (don't ask!) SQL Server instances (2012 SP4, Standard Edition 64-bit)

Change MAXDOP from 0 to 6? Are we likely to gain anything from changing this setting?

4
  • What do your benchmarks say? Commented Sep 18, 2018 at 10:07
  • How would you effectively benchmark this? What would you monitor? Commented Sep 18, 2018 at 10:20
  • 1
    How about NUMA nodes, does SQL Server have NUMA nodes ? Did you tried script mentioned in This SE Thread
    – Shanky
    Commented Sep 18, 2018 at 10:29
  • Some very interesting scripts there, will review these in more detail. Thank you! Commented Sep 18, 2018 at 11:32

1 Answer 1

3

Change MAXDOP from 0 to 6? Are we likely to gain anything from changing this setting?

The short answer is: it depends on your workload and the cpu usage of your queries.

Example 1:

What is your CPU usage, are you seeing spikes on certain queries, are these queries bottlenecking other queries?

If the answer is yes

consider changing your maxdop to 2 or 4. Also, check your cost threshold for parallellism, if this is at the default of 5, consider setting this higher, but as always, monitoring your workload before and after is key.

Example 2:

This one is a bit tricky, since one instance could hog all the resources on your machine.

An important factor in this example is determining which instances are the most critical to always run their queries without possible bottlenecking of the other five instances.

Monitor workload before and after, but leaving it at 0 for all instances and having big queries running at 2 or more instances will cause bottlenecks.

I would consider again setting it to 2 for less important instances and 4 for more important instances to start with, and change this again based on the results. (Here also consider the cost threshold for parallellism setting).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.