May 2, 2014 at 9:17 am
Our high usage OLTP server has MAXDOP = 0 and Cost threshold = 5. (12 cores)
I am wanting start tweaking this with MAXDOP = 5 and Cost threshold = 50 (Good hardware)
Looking into how many cached plans actually use parallelism, I arrived at this query.
SELECT'Cached_Plans' QrySrc,
DB_Name(EQP.dbid) DBName,
OBJECT_NAME(ObjectID, DBID) ObjName,
EPS.Execution_Count,
EPS.Cached_Time,
EQP.Query_Plan
FROMsys.dm_exec_cached_plans ECP
CROSS APPLY sys.dm_exec_text_query_plan(ECP.Plan_Handle,0,-1) EQP
INNER JOIN sys.dm_exec_procedure_stats EPS
ONEQP.[DBID] = EPS.Database_ID
AND EQP.ObjectID = EPS.[Object_ID]
WHEREDBID < 32767
AND EQP.Query_Plan LIKE '%Parallelism%' COLLATE SQL_Latin1_General_CP1_CI_AS
Is this query acturate? It only returns 2 from the 165 stored procedures on this server.
If this is accurate then that means that I have to review all the SPs ensuring nothing is forcing serial plans, as per Paul Whites (SQLKiwi) blog
It's Friday afternoon..... My excuse for the hastily written question. 😀
May 2, 2014 at 10:28 am
Jonathan Kehayias has a query in this blog post[/url] that finds parallel plans in the cache so you could compare your results to his.
Oh, also, it could be that you don't really have performance issues and that CXPACKET just happens to bubble to the top because everything else is working so well. Some wait type has to be the biggest.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
May 3, 2014 at 4:21 am
I'd use Jonathan's query to find the plans.
Also, yours only includes procedures. It doesn't include ad hoc queries. You'd need to hit sys.dm_exec_query_stats for that.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 3, 2014 at 6:15 am
Thanks for help guys.
Jack Corbett (5/2/2014)
Jonathan Kehayias has a query in this blog post[/url] that finds parallel plans in the cache so you could compare your results to his.Oh, also, it could be that you don't really have performance issues and that CXPACKET just happens to bubble to the top because everything else is working so well. Some wait type has to be the biggest.
Thanks for the link. I'll try his query when I'm back in the office.
The server I'm looking into is pretty much maxing out on CPU and I/O. There are a good many Waits that need tending to, I'm just getting started 🙂
Also, yours only includes procedures. It doesn't include ad hoc queries. You'd need to hit sys.dm_exec_query_stats for that.
I did. Without the join to sys.dm_exec_procedure_stat. Same 2 procedures popped up. Nothing else.
I'll will indeed use Jonathan's query.
May 8, 2014 at 3:02 pm
May 9, 2014 at 2:35 am
Jonathans query only returns 8 queries.
OptimizationLvlSubTreeCostusecountssize_in_bytes
FULL250.4238131072
FULL11.585498673728
FULL909.892473728
FULL25.4864163840
FULL112.03424106496
FULL364.273561131072
FULL402.357308229376
FULL231.654594483328
Looks like I need to start tweaking.
Thinking MAXDOP 5, Threshold 10
Maybe a simple question, but how can I best measure the changes?
Can I make these changes during normal hours? (Doesn't matter if cached plans are cleared)
May 9, 2014 at 6:35 am
I'd probably bump the threshold cost up to at least 30 based on the information you have.
You can make this change right in the middle of the day. It's very unlikely to cause issues other than changing which plans run in parallel, so, for the simpler plans, you'll get a recompile.
To measure the impact, I'd focus on those two plans that have a cost of 11 and 25 (assuming you set the threshold higher). See what their execution time is before and after you change the limit. As to the others, same deal, focus on execution times. Those cost estimates are so high, I don't doubt for a minute that those plans are, in all likelihood, good candidates for parallel execution. The other two, not so much.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 9, 2014 at 7:37 am
Best practice for MAXDOP is usually set to it to the number of physical cores in a NUMA node. How did you arrive at 5? Sorry if I missed something.
When I had to tune some servers recently, I started taking measurements using this Paul Randal script[/url] and compared the waits before and after. CXPACKET went from being 25-35% of the waits to 6-7% of the waits. Now they're mostly backup IO and other background process related.
Depending on the server, MAXDOP got either 4 or 6, and I ended up setting the cost threshold for parallelism to (mostly!) 100, but one SPED server got 200 because it's running 2008R2 Standard on almost EOL hardware with 16Gb of memory and it's about to get virtualized.
June 13, 2014 at 8:55 am
Thanks for the input guys.
Sorry for the late post back. Priorities shift a lot here.
(Haven't even starting testing backups yet! Sorry Grant. I'll get to it. I promise.)
I'd probably bump the threshold cost up to at least 30 based on the information you have.
Why is that?
To make sure the majority of the queries are single threaded and use parallel queries relatively sparingly?
Best practice for MAXDOP is usually set to it to the number of physical cores in a NUMA node. How did you arrive at 5? Sorry if I missed something.
I was thinking in the lines of being able to run 2 parallel queries and 2 serial queries simultaneouslyish.
All our machines are virtual.
June 13, 2014 at 10:19 am
Yeah. Those cost estimates can be quite high for fairly simple queries that won't benefit from parallelism. Bumping up the default value is one of the first things I do.
Well, that is, after I test the backups. :w00t:
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 14, 2014 at 11:05 am
Hi everyone, I think that there are two things to take note after adjusting MAXDOP and Cost threshold for parallelism settings. First, as it was mentioned before, take a look at how the waits (CXPACKET) and latches values change. Moreover, it's also important to compare the execution plans before and after and look for changes on Parallel operations.
Additionally, decreasing wait times by adjusting those two settings is good at some point but you cannot forget that those queries were parallelized because of their cost. Hence, you should always go to those costliest queries and see why their cost is so high. Ask yourself:
- Can they be improved?
- What is execution plan telling me?
- Are indexes being used properly?
Sometimes small adjustments in the query change completely their cost.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply