Comments on: CXPACKET? What’s That? And What’s Next?

By: Tahir

Tahir — Sun, 11 Dec 2011 05:59:35 +0000

Excellent post.

By: Michael J Swart

Michael J Swart — Fri, 09 Dec 2011 13:12:32 +0000

High Neil, the query stats are for the statement and the query plan is for the batch. So it’s important to look at the query text to help pinpoint the query in the plan with parallelism.

“high cpu queries using parallelism” is strongly strongly related to “queries that cause CXPACKET”. So if troubleshooting CPU is a concern, I would use the top 20 query without a filter. But for digging into CXPACKET waits, I’ve found the filter works well.

I think these comments jive with your comments. What do you think?

By: Neil Hambly

Neil Hambly — Fri, 09 Dec 2011 12:17:29 +0000

This is a good start.. One thing to note is that although you are identify plans that have parallelism in their QP, these may contain multiple statements of which only some have the parallelism operators and of those it may account for a small percentage of the overall CPU of the batch
Actual Example: a Stored procedure with 2 statements in the plan, 1 of these with 99.9% of the CPU and the other 0.1%, it is only the 0.1% (CPU) statement that has parallelism operators (this was a Clustered index table scan as it was retrieving 70% of the tables rows) so in this case was the required result

As your [Query Text] shows the statement that uses the parallelism operators… in this example that was the 0.1% CPU of the total batch
So we need to wary that this could maybe *not always” be the reason for the HIGH CPU usage – you will need to look further

Of course this is just 1 example and many will be the majority of the CPU and causing performance issues for a variety of reasons (thread skew, blocking or other wait conditions etc..)

By: Michael J. Swart

Michael J. Swart — Fri, 09 Dec 2011 11:39:56 +0000

@Fatherjack, Yes, I can confirm that. I struggled with that, trying to find the best way to mitigate that scenario and I think your change works well. I’ve updated the post. Thanks!

@Merrill, @John, John’s right. CXPACKET isn’t bad in itself just like blocking isn’t bad in itself. It’s excessive blocking and excessive CXPACKET that’s the problem. In my head, the audience for this article is someone who is managing an OLTP database and who sees a lot of parallelism. This means some query is doing a lot of work. That’s not bad in itself. Sometimes queries need to do a lot of work. The question that should be asked is whether this query is doing too much work. Before you can answer that, you need to know which queries those are. My hope is that this post helps with that.

By: Fatherjack

Fatherjack — Fri, 09 Dec 2011 11:26:39 +0000

Michael, I am getting a number of false positives with your code (ie queries where there isnt parallelism in the plan). It seems to be most often when the execution count is high so I would guess that its down to a rounding effect somewhere in the work.

If you take the difference between the Total CPU and the Total Elapsed Time and divide that by the number of executions and you get 0 then these plans dont have any parallelism operators. Adding “( ( total_worker_time – total_elapsed_time ) / execution_count ) * 1.0 > 1000″ to your WHERE clause gives me results with no false positives.

Can you confirm any details in this scenario please?

By: Something for the Weekend – SQL Server Links 09/12/11

Something for the Weekend – SQL Server Links 09/12/11 — Fri, 09 Dec 2011 11:08:37 +0000

[...] CXPACKET? What’s That? And What’s Next? - Cooking up some CXPACKET Waits can be a recipe for disaster. Performance tuning head chef Michael J. Swart (Blog|Twitter) walks us through. [...]

By: John Sansom

John Sansom — Fri, 09 Dec 2011 09:48:27 +0000

Fantastic, another great post Michael. I particularly enjoyed the novel use of the good ole “Too may cooks…” analogy.

Merrill, in the post Michael eludes that it’s more geared toward analysing the occurrence of parallel queries for OLTP workloads.

Far be it from me to put words into the man’s mouth but my own understanding is that in such scenarios it is particularly undesirable to see a parallel plan being produced given that the goal is for short lived/fast transactions which are often performing relatively small data reads/writes. Seeing a parallel query plan produced for OLTP workloads is often an indicator of a poor plan choice/issue, such as a poorly written query or missing indexes.

By: Merrill Aldrich

Merrill Aldrich — Fri, 09 Dec 2011 06:07:49 +0000

Interesting – but I have a question: you seem automatically to equate parallel with “bad.” Parallel does not automatically imply badness. How do you separate the good parallel queries from the ones where the parallel processing actually does harm and a single threaded plan would be better?