การจัดการกับ CXPACKET รอ - ตั้งค่าขีด จำกัด ต้นทุนสำหรับการขนาน

จากการติดตามคำถามก่อนหน้านี้เกี่ยวกับการแก้ไขปัญหาเว็บไซต์ SharePointอย่างสมบูรณ์ฉันสงสัยว่าฉันสามารถทำบางสิ่งเกี่ยวกับ CXPACKET ได้หรือไม่

ฉันรู้ว่าวิธีแก้ปัญหาข้อเข่ากระตุกคือการปิดความขนานทั้งหมดโดยการตั้งค่า MAXDOP เป็น 1 - ฟังดูเหมือนเป็นความคิดที่ไม่ดี แต่แนวคิดอื่นคือการเพิ่มเกณฑ์ต้นทุนก่อนที่จะเริ่มขนานกันเริ่มต้นที่ 5 สำหรับต้นทุนของแผนการดำเนินการค่อนข้างต่ำ

ดังนั้นฉันจึงสงสัยว่ามีคำถามที่เขียนไว้แล้วว่าจะพบคำค้นหาที่มีค่าใช้จ่ายแผนปฏิบัติการสูงที่สุด (ฉันรู้ว่าคุณสามารถค้นหาสิ่งที่มีระยะเวลาดำเนินการสูงสุดและอื่น ๆ ได้) แต่เป็นต้นทุนแผนปฏิบัติการที่เรียกคืนได้ ด้วยหรือไม่) และนั่นก็จะบอกฉันด้วยว่ามีการดำเนินการค้นหาแบบขนานหรือไม่

ใครบ้างมีสคริปต์ดังกล่าวในมือหรือสามารถชี้ให้ฉันไปในทิศทางของมุมมอง DMV, DMF หรือแคตตาล็อกระบบอื่น ๆ ที่เกี่ยวข้องเพื่อค้นหาสิ่งนี้?

CXPACKETไม่เคยเป็นสาเหตุ; มันได้รับโทษทั้งหมด แต่ก็เป็นอาการของสิ่งอื่นเสมอ คุณต้องค้นหาข้อความเหล่านี้ในการกระทำและหาว่า "อย่างอื่น" คืออะไร มันอาจจะแตกต่างจากแบบสอบถามไปยังแบบสอบถามและปิดขนานกันคือ - ตามที่คุณแนะนำ - overkill ไม่จำเป็นในกรณีส่วนใหญ่ แต่บ่อยครั้งที่จำนวนงานน้อยที่สุดซึ่งเป็นเหตุผลว่าทำไมมันถึงเป็น "การแก้ไข" ที่แพร่หลาย

หากคุณสามารถได้รับจริงแผนสำหรับการค้นหาที่ดูเหมือนว่าจะต้องรับผิดชอบในการรอ CXPACKET สูงโหลดลงในSQL ยามแผน Explorer ที่ มักจะมีเหตุผลที่อยู่เบื้องหลังสิ่งนี้ เราแสดงว่าการดำเนินการแบบขนานใดที่นำไปสู่การเอียงของเธรดและคุณสามารถเชื่อมโยงการประมาณนั้นกับการปิดได้อย่างง่ายดาย โดยปกติแล้วปัญหาพื้นฐานนั้นเป็นสถิติที่ไม่ดี / ล้าสมัย (หรือไม่พร้อมใช้งาน)

น่าเสียดายที่สิ่งที่คุณจะพบใน sys.dm_exec_cached_plans เป็นแผนโดยประมาณ พวกเขาจะไม่บอกคุณว่าแผนนั้นขนานกันเมื่อใช้จริงหรือไม่เพราะแผนจริงไม่ใช่สิ่งที่แคชไว้ ในบางกรณีคุณคาดว่าจะเห็นทั้งแผนอนุกรมและขนานสำหรับแบบสอบถามเดียวกัน นี่ไม่ใช่วิธีที่ SQL Server จัดการกับสถานการณ์สำหรับแผนขนานที่อาจขนานกันขณะใช้งานจริง (มีข้อมูลมากมายเกี่ยวกับที่นี่ )

หากคุณต้องการดูแผนการดำเนินการจริงของแบบสอบถามที่กำลังทำงานอยู่

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 ลงอย่างมาก

หวังว่าจะช่วย

คำตอบข้างต้นโดย Aaron ถูกต้อง

ฉันแค่อยากจะเพิ่มสิ่งนั้นถ้าคุณยังไม่ได้ใช้รายงานแดชบอร์ดประสิทธิภาพ SQLและตัวรวบรวมข้อมูลในตัวคุณควรเริ่มต้น

คุณสามารถใช้แบบสอบถามต่อไปนี้และแก้ไขตามที่เห็นว่าเหมาะสม:

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

จากประสบการณ์ที่ผ่านมาเกณฑ์ต้นทุนสำหรับความเท่าเทียมไม่ได้ช่วยลด CXPACKET

การCXPACKETรอคอยสูงสามารถเกิดขึ้นได้เนื่องจากสถิติที่ไม่ถูกต้องส่งผลให้เกิด Parallellism แบบเบ้

1. เพิ่มเติมเกี่ยวกับ CXPACKET กำลังรอ: Parallelism เบ้
2. รายการ Microsoft Connect
3. ข้อความค้นหาของฉันคือ (ไม่) กำลังรอเพราะความเท่าเทียมกันหรือไม่ - ทิมฟอร์ด

ต่อไปนี้คือ SQL ฉันใช้เพื่อค้นหาเซสชันที่มีทั้งCXPacketและ " other waits " อยู่ข้างใน (โปรดดูที่ dagram ด้านล่าง)

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]

การสแกนขนาดใหญ่สามารถเป็นส่วนหนึ่งของสาเหตุที่แท้จริงได้ เมื่อฉันตรวจสอบแผนการดำเนินการจากแบบสอบถามด้านบนฉันพบการสแกนหนึ่งรายการในฐานข้อมูลของฉัน นอกจากนี้ยังมีข้อเสนอแนะดัชนีที่ขาดหายไปในแผนการดำเนินการ