处理CXPACKET等待-设置并行性的成本阈值

12

作为我先前对Sharepoint网站进行性能故障的先前问题的补充，我想知道我是否可以对CXPACKET等待做点什么。

我知道下意识的解决方案是通过将MAXDOP设置为1来关闭所有并行性-听起来是个坏主意。但是另一个想法是在并行开始之前增加成本阈值。执行计划成本的默认值5相当低。

因此，我想知道是否存在已经写好的查询，该查询将为我找到执行计划成本最高的查询（我知道您可以找到执行时间最长的查询，依此类推-但是执行计划成本是否可在某处检索到，也可以），这还会告诉我是否已经并行执行了这样的查询。

是否有人手头有这样的脚本，或者可以将我指向相关DMV，DMF或其他系统目录视图的方向，以找出答案？

— marc_s
source

11

CXPACKET永远不是原因这一切都应归咎于它，但这始终是其他事情的征兆。您需要在行为中捕获这些查询并弄清楚什么是“其他”。每个查询的查询可能有所不同，并且关闭并行性（如您所建议的）在大多数情况下完全是不必要的。但这通常是最少的工作量，这就是为什么它是如此流行的“解决方案”的原因。

如果您可以为似乎引起高CXPACKET等待的查询获取实际计划，则将其加载到SQL Sentry Plan Explorer中。这通常是有原因的；我们将显示哪些并行操作导致线程偏斜，并且您可以轻松地将其与不正确的估算值相关联（我们以估算值偏离至少一定阈值的方式突出显示操作）。通常，潜在的问题实际上是错误的/过时的（或不可用的）统计信息。

不幸的是，您在sys.dm_exec_cached_plans中发现的只是估计的计划。他们不会告诉您该计划在实际使用时是否平行，因为实际的计划不是缓存的。在某些情况下，您希望同时看到同一查询的串行和并行计划。这不是SQL Server如何处理可能在运行时并行的并行计划的情况。（有关此的很多信息。）

— 亚伦·伯特兰
source

4

如果您希望查看正在运行的查询的实际执行计划。

SELECT plan_handle FROM sys.dm_exec_requests WHERE session_id = [YourSPID]

首先，将结果输入此查询。

SELECT query_plan FROM sys.dm_exec_query_plan (Enter the result here.)

这将显示sql用于该查询的实际执行计划。您可以使用该执行计划来查看正在等待的线程。

我还发现关闭超线程可以大大减少CXpacket的等待时间。

希望能有所帮助。

— 赞恩
source

3

上述亚伦的答案是正确的。

我想补充一下，如果您还没有使用SQL Performance Dashboard Reports和内置的Data Collector，那么应该开始。

您还可以采用以下查询，并根据需要对其进行修改：

DECLARE @MinExecutions int; 
SET @MinExecutions = 5 

SELECT EQS.total_worker_time AS TotalWorkerTime 
      ,EQS.total_logical_reads + EQS.total_logical_writes AS TotalLogicalIO 
      ,EQS.execution_count As ExeCnt 
      ,EQS.last_execution_time AS LastUsage 
      ,EQS.total_worker_time / EQS.execution_count as AvgCPUTimeMiS 
      ,(EQS.total_logical_reads + EQS.total_logical_writes) / EQS.execution_count  
       AS AvgLogicalIO 
      ,DB.name AS DatabaseName 
      ,SUBSTRING(EST.text 
                ,1 + EQS.statement_start_offset / 2 
                ,(CASE WHEN EQS.statement_end_offset = -1  
                       THEN LEN(convert(nvarchar(max), EST.text)) * 2  
                       ELSE EQS.statement_end_offset END  
                 - EQS.statement_start_offset) / 2 
                ) AS SqlStatement 
      -- Optional with Query plan; remove comment to show, but then the query takes !!much longer!! 
      --,EQP.[query_plan] AS [QueryPlan] 
FROM sys.dm_exec_query_stats AS EQS 
     CROSS APPLY sys.dm_exec_sql_text(EQS.sql_handle) AS EST 
     CROSS APPLY sys.dm_exec_query_plan(EQS.plan_handle) AS EQP 
     LEFT JOIN sys.databases AS DB 
         ON EST.dbid = DB.database_id      
WHERE EQS.execution_count > @MinExecutions 
      AND EQS.last_execution_time > DATEDIFF(MONTH, -1, GETDATE()) 
ORDER BY AvgLogicalIo DESC 
        ,AvgCPUTimeMiS DESC

— tacotuesday
source

0

在我以前的经验中，并行成本阈值并不能帮助降低CXPACKET。

CXPACKET由于不正确的统计信息会导致高等待时间，从而导致偏斜现象。

以下是我用来查找同时包含CXPacket和“ 其他等待 ”的会话的SQL （请参见下面的数据）。

的SQL

DECLARE @RawResult TABLE ([database_id] INT,[session_id] INT,exec_context_id INT, [blocking_session_id] INT,task_state VARCHAR(20),
                          [cpu_time] BIGINT,[wait_duration_ms] BIGINT, [wait_type] VARCHAR(100),[resource_description] nvarchar(3072),
                          [sql_handle] varbinary(64),[plan_handle] varbinary(64)
                          )
INSERT INTO @RawResult
SELECT 
    [R].[database_id],
    [S].[session_id],
    [W].exec_context_id,
    [W].blocking_session_id,
    [T].task_state,
    [R].[cpu_time],
    [W].[wait_duration_ms],
    [W].[wait_type],
    [W].[resource_description],
    [R].[sql_handle],
    [R].[plan_handle]
FROM sys.dm_os_waiting_tasks [W]
INNER JOIN sys.dm_os_tasks [T] ON
    [W].[waiting_task_address] = [T].[task_address]
INNER JOIN sys.dm_exec_sessions [S] ON
    [W].[session_id] = [S].[session_id]
INNER JOIN sys.dm_exec_requests [R] ON
    [S].[session_id] = [R].[session_id]
WHERE [S].[is_user_process] = 1
--AND S.session_id <> @@SPID--???
--ORDER BY [W].[session_id],[W].[exec_context_id];


SELECT  
    DB_NAME(C.database_id) AS database_name,
    C.[database_id],
    C.[session_id],
    C.exec_context_id,
    C.blocking_session_id,
    C.task_state,
    C.[cpu_time],
    C.[wait_duration_ms],
    C.[wait_type],
    C.[sql_handle],
    C.[plan_handle],
    [H].text,
    [P].[query_plan],
    C.[resource_description]
FROM @RawResult C
OUTER APPLY sys.dm_exec_sql_text (C.[sql_handle]) [H]
OUTER APPLY sys.dm_exec_query_plan (C.[plan_handle]) [P]
WHERE C.[session_id] IN
                    (
                        SELECT A.[session_id]
                        FROM @RawResult A
                        INNER JOIN @RawResult B
                            ON A.[session_id] = B.[session_id]
                            AND A.wait_type='CXPACKET'
                            AND B.wait_type <> 'CXPACKET'
                    )
ORDER BY C.[session_id],C.[exec_context_id]

大型扫描也可能是根本原因的一部分。当我从上述查询中检查执行计划时，我在数据库中发现了一个这样的扫描。执行计划中也缺少索引建议。

— LCJ
source