Are problems with parallelism more common today? What issues can arise from parallelism?

Question

This is a very general question so I don't give much specific information. I am more interested in parallelism and its possible drawbacks. Generally I am all for parallelism as something useful and positive.

I seem to come across more and more systems that have one or more stored procedure that have issues with too much parallelism. Is there a good way to find out if that really is the problem or if it is something else lurking about?

Usually the sql is a bit complex with maybe 5 or more joins and also some udf and even more complexity. So far I found these issues by examining everything from usual performance issues but also from more extreme situations with error messages like "Could not create thread..." and also deadlocks from multiple simultaneous copies of the same store procedure.

I am really curious how you guys do to find issues like these and also how you go about solving them. Recoding? Playing with MAXDOP (max degree of parallelism)? And so on...

Answer 1

I wrote about six potential issues with parallelism here:

• https://sqlblog.org/2009/03/21/six-reasons-you-should-be-nervous-about-parallelism

That was three years ago, and I'm sure other equally dangerous bugs have come up since I wrote that. I haven't gone through and validated any that have been reported as fixed, but the workaround is almost always to use MAXDOP 1.

And there's another one that is still an issue in SQL Server 2012, and that hasn't been fixed in CU1:

• https://stackoverflow.com/questions/9523213/possible-bug-with-range-option-of-window-aggregates-and-parallel-plans-in-sql-se

• http://connect.microsoft.com/SQLServer/feedback/details/728932/parallelism-bug-with-sum-over-and-range

The workaround in that case is, again, to use MAXDOP 1.

There are other issues that can be blamed on parallelism that aren't really parallelism's fault. For example if your statistics are way off you can observe behavior where parallelism is employed but a single thread is doing all the work. This is the case where people sound the alarms because they're seeing CXPACKET waits and they think that parallelism is causing the problem, when in fact it is the victim. The knee-jerk reaction in those cases is typically to employ MAXDOP instead of investigating further and resolving the statistics issue or other root cause.

It's not clear what you mean by "too much parallelism" or whether your deadlocks and other issues are in fact related in any way to parallelism. In general I agree that parallelism is a positive thing but it is important to be aware of the potential issues above and also to be able to discern symptom from cause.

Answer 2

Being able to commit more CPU cores to the processing of a request is a good thing, until the time it takes to reassemble the results exceeds the gain obtained from distributing the workload.

Check to see if you have high CXPACKET wait time. If you don't, then no worries. That article gives you some things to try if you want to gain more understanding on the issue.