การแก้ไขปัญหา SOS_SCHEDULER_YIELD รอ

ใช้ ERP ในองค์กรของเรา (Dynamics AX 2012) ฉันสังเกตว่าสภาพแวดล้อมการผลิตของเรานั้นช้ากว่าระบบการพัฒนาของเรามาก

หลังจากทำกิจกรรมเดียวกันทั้งในสภาพแวดล้อมการพัฒนาและการใช้งานจริงในขณะทำการสืบค้นกลับฉันยืนยันว่าข้อความค้นหา SQL กำลังทำงานช้ามากในสภาพแวดล้อมการผลิตของเราเมื่อเทียบกับการพัฒนา (เฉลี่ย 10-50x ช้ากว่า)

ตอนแรกฉันอ้างว่าสิ่งนี้เพื่อโหลดและเรียกใช้กิจกรรมเดียวกันอีกครั้งในสภาพแวดล้อมการผลิตในช่วงนอกเวลาทำงานและพบผลลัพธ์เดียวกันในการติดตาม

ฉันล้างสถิติการรอของฉันใน SQL Server แล้วปล่อยให้เซิร์ฟเวอร์ทำงานภายใต้ปริมาณการผลิตตามปกติชั่วครู่หนึ่งจากนั้นเรียกใช้แบบสอบถามนี้:

WITH [Waits] AS
    (SELECT
        [wait_type],
        [wait_time_ms] / 1000.0 AS [WaitS],
        ([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS],
        [signal_wait_time_ms] / 1000.0 AS [SignalS],
        [waiting_tasks_count] AS [WaitCount],
        100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage],
        ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum]
    FROM sys.dm_os_wait_stats
    WHERE [wait_type] NOT IN (
        N'CLR_SEMAPHORE',    N'LAZYWRITER_SLEEP',
        N'RESOURCE_QUEUE',   N'SQLTRACE_BUFFER_FLUSH',
        N'SLEEP_TASK',       N'SLEEP_SYSTEMTASK',
        N'WAITFOR',          N'HADR_FILESTREAM_IOMGR_IOCOMPLETION',
        N'CHECKPOINT_QUEUE', N'REQUEST_FOR_DEADLOCK_SEARCH',
        N'XE_TIMER_EVENT',   N'XE_DISPATCHER_JOIN',
        N'LOGMGR_QUEUE',     N'FT_IFTS_SCHEDULER_IDLE_WAIT',
        N'BROKER_TASK_STOP', N'CLR_MANUAL_EVENT',
        N'CLR_AUTO_EVENT',   N'DISPATCHER_QUEUE_SEMAPHORE',
        N'TRACEWRITE',       N'XE_DISPATCHER_WAIT',
        N'BROKER_TO_FLUSH',  N'BROKER_EVENTHANDLER',
        N'FT_IFTSHC_MUTEX',  N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
        N'DIRTY_PAGE_POLL',  N'SP_SERVER_DIAGNOSTICS_SLEEP')
    )
SELECT
    [W1].[wait_type] AS [WaitType],
    CAST ([W1].[WaitS] AS DECIMAL(14, 2)) AS [Wait_S],
    CAST ([W1].[ResourceS] AS DECIMAL(14, 2)) AS [Resource_S],
    CAST ([W1].[SignalS] AS DECIMAL(14, 2)) AS [Signal_S],
    [W1].[WaitCount] AS [WaitCount],
    CAST ([W1].[Percentage] AS DECIMAL(4, 2)) AS [Percentage],
    CAST (([W1].[WaitS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgWait_S],
    CAST (([W1].[ResourceS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgRes_S],
    CAST (([W1].[SignalS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgSig_S]
FROM [Waits] AS [W1] INNER JOIN [Waits] AS [W2] ON [W2].[RowNum] <= [W1].[RowNum]
GROUP BY [W1].[RowNum], [W1].[wait_type], [W1].[WaitS],
    [W1].[ResourceS], [W1].[SignalS], [W1].[WaitCount], [W1].[Percentage]
HAVING SUM ([W2].[Percentage]) - [W1].[Percentage] < 95; -- percentage threshold

ผลลัพธ์ของฉันมีดังนี้:

WaitType               Wait_S  Resource_S  Signal_S  WaitCount  Percentage  AvgWait_S  AvgRes_S  AvgSig_S
SOS_SCHEDULER_YIELD   4162.52        3.64   4158.88    4450085       77.33     0.0009    0.0000    0.0009
ASYNC_NETWORK_IO       457.98      331.59    126.39     351113        8.51     0.0013    0.0009    0.0004
PAGELATCH_EX           252.94        5.14    247.80     796348        4.70     0.0003    0.0000    0.0003
WRITELOG               166.01       48.01    118.00     302209        3.08     0.0005    0.0002    0.0004
LCK_M_U                145.47      145.45      0.02        123        2.70     1.1827    1.1825    0.0002

ดังนั้นการรอที่ใหญ่ที่สุดก็คือ SOS_Scheduler_Yield ในตอนนี้และฉันก็วนไปรอบ ๆ และพบว่าโดยทั่วไปแล้วมันเกี่ยวข้องกับซีพียูที่ไม่สามารถติดตามได้

จากนั้นฉันเรียกใช้แบบสอบถามนี้หลายครั้งติดต่อกัน

SELECT *
FROM sys.dm_os_schedulers
WHERE scheduler_id < 255

ฉันรู้ว่าฉันควรจะมองหา schedulers ที่ไม่มี runnable_tasks_count หรือ pending_disk_io_count ที่ไม่ใช่ศูนย์ แต่โดยทั่วไปแล้วจะเป็นศูนย์เกือบตลอดเวลา

ฉันควรพูดถึงว่า Max degree of Parallelism ถูกตั้งค่าเป็น 1 เนื่องจากภาระงาน Dynamics AX โดยทั่วไปคือ OLTP โดยธรรมชาติและการเปลี่ยนเป็น 8 ไม่ได้สร้างความแตกต่างอย่างมากในสถิติการรอคอยข้างต้นพวกเขาเกือบจะเหมือนกันทุกประการ ปัญหาประสิทธิภาพการทำงาน

ฉันสูญเสียสถานที่ที่จะไปจากที่นี่ฉันโดยทั่วไปมี SQL Server ที่ดูเหมือน CPU รัด แต่ไม่รอ runnable_tasks หรือ IO

ฉันรู้ว่าระบบย่อย IO ของ SQL Server นี้ไม่ดีมากเพราะการใช้ SQLIO บนไดรฟ์ที่มีฐานข้อมูลจริงสามารถนำไปสู่ตัวเลขที่ค่อนข้างต่ำ (คิด 10MB ต่อวินาทีสำหรับการอ่าน / เขียนบางประเภท) ที่กล่าวว่า ดูเหมือนว่า SQL จะไม่รอเพราะจำนวนหน่วยความจำบนเซิร์ฟเวอร์แคชฐานข้อมูลส่วนใหญ่

นี่คือข้อมูลสภาพแวดล้อมบางอย่างที่จะช่วย:

สภาพแวดล้อมการผลิต:

• เซิร์ฟเวอร์ SQL
• HP ProLian DL360p Gen8
• Intel Xeon E5-2650 0 @ 2.00GHz x 2 พร้อมไฮเปอร์เธรด (32 แกนตรรกะ)
• หน่วยความจำ 184GB
• Windows Server 2012
• อินสแตนซ์ของ SQL Server 2012 Standard 2 รายการ (RTM, unpatched)
• Raid 1 279GB ไดรฟ์ (15k) C: ไดรฟ์ประกอบด้วยฐานข้อมูลและระบบปฏิบัติการ
• Page File และ TempDB บนไดรฟ์ที่แยกต่างหากที่แยกต่างหาก (โซลิดสเตต)

DEV ของฉัน:

• Hyper-V โฮสต์เซิร์ฟเวอร์ SQL เซิร์ฟเวอร์และเซิร์ฟเวอร์ AOS Dynamics AX 2012
• Core i7 3.4 กิกะเฮิร์ตซ์พร้อมไฮเปอร์เธรด (8 แกนตรรกะ)
• หน่วยความจำ 8GB
• Windows Server 2008 R2
• SSD สำหรับ VM ทั้งหมด

ฉันยินดีต้อนรับการป้อนข้อมูลในสิ่งอื่น ๆ เพื่อค้นหา

ดังนั้นฉันจึงแก้ไขปัญหานี้ปรากฎว่ามีการเปิดใช้งานคุณสมบัติการจัดการพลังงานบนเซิร์ฟเวอร์ SQL ของเราซึ่งปรับความถี่ CPU ขึ้นและลง แต่ไม่เร็วพอที่จะตอบสนองความต้องการขนาดเล็กและแนะนำการรอคอย SOS_Scheduler_Yield หลังจากเปลี่ยนให้ทำงานอย่างมีประสิทธิภาพสูงปัญหาจะหายไปและตอนนี้การรอเป็นเรื่องปกติมากขึ้น (ประเภทของ LatchIO)