A ticket opened recently with Microsoft support involved changing a the max degree of parallelism on the SQL server.
I had not used or heard of this setting before, which isn’t a surprise I tend to leave SQL Server settings to the people who know more about the consequences.
Early in the year I did look at effects of changing the SQL Server trace flag 8780 which resulted in reports running faster but is unsupported unless Microsoft support teams advices you to do it!
My goal in this blog is to give an overview about max degree of parallelism Option and some links to more information.
Remember to always consider the effects of changing flags and options, they can change results/efficiency in other SQL queries
What is max degree of parallelism Option
The place to start is the MSDN article
When SQL Server runs on a computer with more than one microprocessor or CPU, it detects the best degree of parallelism, that is, the number of processors employed to run a single statement, for each parallel plan execution. You can use the max degree of parallelism option to limit the number of processors to use in parallel plan execution. The default value of 0 uses all available processors up to 64 CPUs
You can learn more about Degree of Parallelism in this specific article
This max degree of parallelism controls how many processors in the SQL server can be used on any one single query.
The default value for Max degree of parallelism is set to 0, this means there is no limit to the number of processors.
If you change the option to a number e.g. 1, you are then limiting the SQL server to use one processor for each query.
This setting seems to be changed when users want to limit the number of processors used in single queries to stop SQL server taking all the processors for single queries.
The setting is also used to increase the number to improve performance in single queries.
This is a server side setting so you need to consider how changing this setting could effect the performance of all SQL queries on the SQL server (and maybe not just CRM)
This article is very useful because it mentions limitations and restrictions and recommedations
This recommendations I found interesting
- This option is an advanced option and should be changed only by an experienced database administrator or certified SQL Server technician.
- To enable the server to determine the maximum degree of parallelism, set this option to 0, the default value. Setting maximum degree of parallelism to 0 allows SQL Server to use all the available processors up to 64 processors. To suppress parallel plan generation, set max degree of parallelism to 1. Set the value to a number from 1 to 32,767 to specify the maximum number of processor cores that can be used by a single query execution. If a value greater than the number of available processors is specified, the actual number of available processors is used. If the computer has only one processor, the max degree of parallelism value is ignored.
- You can override the max degree of parallelism value in queries by specifying the MAXDOP query hint in the query statement. For more information, see Query Hints (Transact-SQL).
It seems to suggest you can set it on an individual query basis.
Here is another article
How to change the Max degree of parallelism Option
It’s an SQL option so set the value using an sql statement.
I took the code from this page
exec sp_configure 'show adv', 1; RECONFIGURE WITH OVERRIDE; exec sp_configure 'max degree', 1 RECONFIGURE WITH OVERRIDE; Exec sp_configure
How does is this setting used with CRM
Take into account I have not had any personal experience changing this setting, I saw it was mentioned as a possible resolution, I decided to investigate.
This setting usually effects CRM if you have multiple long running queries. It can cause the CRM performance to slow.
This article talks about CRM 4
In the example above it seems the SQL server was using all the processors on one long running query which caused performance of CRM in general to slow down. It limits sets the MAXDOP to 1 to stop this.
This article is very good and the blog looks into the setting in detail
The article concludes it’s probably best to tinker with this setting only if your having slow performance from your SQL server/CRM.
Interesting forum discussions