How to find SPs with parallel plans? Really this simple?

  • Our high usage OLTP server has MAXDOP = 0 and Cost threshold = 5. (12 cores)

    Top wait is CXPacket[/url]

    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. 😀

  • 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.

  • 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

  • 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.

  • I've always had good luck with this query[/url], though I've never compared the results or performance to the Jonathan Kehayias query.

  • 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)

  • 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

  • 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.

  • 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.

  • 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

  • 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