CXPACKET SUSPENDED and NULL wait type

Question

I was was running the query in this article:

http://sqlity.net/en/708/why-cxpacket-waits-are-not-your-performance-problem/

To see what my threads were waiting on in regards to a suspended query with a wait type of CXPACKET.

However for the SPID in question threads that are running were showing wait types of NULL with every other thread in a SUSPENDED state with a wait type of CXPACKET.

I was expecting to one of the threads having some kind of wait type other than CXPACKET, can anyone explain to me what is happening in this situation?

Thanks

Answer 1

What you're seeing is the threads with CXPACKET waits are actually done with whatever work they had to do and are now waiting for the other active threads (the ones with NULL as the wait type) to complete.

Brent O had a great analogy using a classroom. The teacher hands out a bunch of different stacks of paper to the class and has them find a word on them. What we need to take into consideration is the fact that 1) the stacks of paper could be different sizes 2) different students read faster/slower than others 3) one student may find the word 1 time on the first page, while the next could find it 400 times across 3000 pages.

You're seeing a natural and intended behavior when you deal with parralelism, some threads finish faster than others and are forced to wait until the other threads complete, regather all the threads and give you an output.

http://www.brentozar.com/archive/2013/08/what-is-the-cxpacket-wait-type-and-how-do-you-reduce-it/

Answer 2

The CXPACKET was always the confusing wait type for younger DBAs and some predictably wrong reactions are generally expected. There are multiple acpects of the CXPACKLET wait type and I've tried in Troubleshooting the CXPACKET wait type in SQL Server article to bring on the table most of the reasons for high CXPACKET but also to explain the background of the CXPACKET, as the proper understanding of parallelism in SQL Server is the key for understanding

So for those who don't want to get in details, I will post the summary of the article here (but I would definitely suggest reading of the article for complete info about CXPACKET wait type):

• Do not set MAXDOP to 1, as this is never the solution

• Investigate the query and CXPACKET history to understand and determine whether it is something that occurred just once or twice,
  as it could be just the exception in the system that is normally
  working correctly

• Check the indexes and statistics on tables used by the query and make sure they are up to date

• Check the Cost Threshold for Parallelism (CTFP) and make sure that the value used is appropriate for your system

• Check whether the CXPACKET is accompanied with a LATCH_XX (possibly with PAGEIOLATCH_XX or SOS_SCHEDULER_YIELD as well). If this is the
  case than the MAXDOP value should be lowered to fit your hardware

• Check whether the CXPACKET is accompanied with a LCK_M_XX (usually accompanied with IO_COMPLETION and ASYNC_IO_COMPLETION). If this is
  the case, then parallelism is not the bottleneck. Troubleshoot those
  wait stats to find the root cause of the problem and solution