A. Execute exec sp_configure ‘maximum degree of parallesism’, 1

B. Execute exec sp_configure ‘maximum degree of parallesism’, 8

C. Use SQL Profiler to identify queries tha experience CXPACKET wait. Add (OPTION MAXDOP 1) to each query.

D. Use SQL Profiler to identify queries tha experience CXPACKET wait. Add (OPTION MAXDOP 8) to each query.

Please answer the question.
Thank you,
Bidhan

-Manoj

This was wonderful article and comments. Really appreciate it.

In the interest of full disclosure, I’ll mention that Adam Machanic disagrees with this, and suggests that OLTP should “lean toward” MAXDOP 2, but to me this is just opening up the door to parallel plans that you don’t want to happen, and which will take cycles away from well-behaved queries. It also would encourage people to write code that needs to go parallel. With MAXDOP 1 as our server setting, we need to request other MAXDOP settings explicitly in our code, and that’s good because that means it will be obvious to the code reviewer that the query is intended to go parallel.

For OLAP / Reporting / DSS (there’s an old TLA) and similar systems, I agree that MAXDOP 0 could be appropriate, but again, that allows one rogue process to take over your server. Setting MAXDOP equal to the number of cores (or half the number of cores) and overriding that only when you need more is another strategy that could work. For those servers, I think it really depends on whether it’s OK with you to have individual requests chewing up all your schedulers at once.

Cheers,
Chris

First of all – you are very much correct and have grasped the intention. Thanks for your comment, I think this will clear it up if there is any confusion.

Coordinator thread is very important and it waits for incomplete thread. I have earlier dug into that and here is the bit explanation on the subject : http://blog.sqlauthority.com/2010/07/11/sql-server-parallelism-row-per-processor-row-per-thread-thread-0/

Again, as I said, I had great fun attending your sessions. I learned a lot from you to apply to my clients. Meeting you was very good experience and only fortunate will have it.

Many thanks,

Kind Regards,
Pinal

As always, great article! I would like to highlight a particular rule of thumb that we use with our Enterprise product. (I agree with you that the correct answer is “it depends”, but at least for our systems, the below seems to be working, making it a golden rule for us).

Snehal: This is what might help you also.

Our system has it’s roots as a legacy system from the days of flat-file database systems (about 20 years ago). It has grown over the years to now use SQL 2008 R2. The point behind mentioning this bit of history is that most of our queries are tuned on running against a single processor. Our warehouse product is, of course a “modern” product (developed in the days of SQL 2000) and quite a few of the OLAP queries are tuned for sound multi-processor performance.
As a general rule, because our OLTP and OLAP systems are deployed on different physical machines (not only different SQL instances), we tend to recommend that the MAXDOP on the OLTP system be 1 and that on the OLAP be 0.
Doing vice-versa would toast the performance of both systems, as is the case with Snehal.

Snehal: If your reporting and OLTP systems are fused and/or cannot be separated, I would say that your reporting stored procedures should be modified to use MAXDOP 0. The server level setting should be 1.

Thanks & Regards,
Nakul Vachhrajani.

In a hybrid environment (reads and writes) you may want to adjust the maxdop settings accordingly, IF it becomes an issue – exactly monitoring the waitstats for high occurrence of CXPACKETS. HTH

- RP

Also, keep in mind that if you have a mixed workload on the same instance it is best to find the correct setting for the threshold of parallelism and not the Degree of parallelism, but this is a whole different subject.

Also, as Snehal is asking, in a case where you have a system with a mixed workload, it would be a good idea to consider segregation of the workload. I usually put systems with different workload types on different instances, or even on virtual machines. I design them like that to begin with because it is easier to manage.

It was nice to meet you this week in Seattle. I have one comment on this post:

“Note that CXPACKET Wait is done by completed thread and not the one which are unfinished.”

Specifically, it is the coordinator / boss thread that registers CXPACKET waits. The child / worker threads do not experience this wait state. The coordinator will always experience this wait as long as at least one child has not yet completed.

Cheers,
Chris