Khắc phục sự cố chờ đợi SOS_SCHEDULER_YIELD

Vận hành ERP công ty của chúng tôi (Dynamics AX 2012), tôi nhận thấy môi trường sản xuất của chúng tôi dường như chậm hơn nhiều so với các hệ thống phát triển của chúng tôi.

Sau khi thực hiện các hoạt động tương tự trong cả môi trường phát triển và sản xuất trong khi chạy theo dõi, tôi xác nhận rằng các truy vấn SQL đang thực thi rất chậm trên môi trường sản xuất của chúng tôi so với phát triển (trung bình chậm hơn 10-50 lần).

Lúc đầu, tôi cho rằng điều này là tải, và chạy lại các hoạt động tương tự trên môi trường sản xuất trong giờ nghỉ và tìm thấy kết quả tương tự trong dấu vết.

Tôi đã xóa số liệu thống kê chờ đợi của mình trong SQL Server sau đó để máy chủ chạy dưới tải sản xuất bình thường trong một thời gian và sau đó chạy truy vấn này:

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

Kết quả của tôi như sau:

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

Vì vậy, dường như sự chờ đợi lớn nhất là SOS_Scheduler_Yield và tôi đã đi vòng quanh và thấy nó thường liên quan đến việc CPU không thể theo kịp.

Sau đó tôi đã chạy truy vấn này nhiều lần liên tiếp.

SELECT *
FROM sys.dm_os_schedulers
WHERE scheduler_id < 255

Tôi biết rằng tôi nên tìm kiếm những người lập lịch với runnable_t Nhiệm_count hoặc cấp phát_isk_io_count, nhưng về cơ bản thì hầu như không có thời gian.

Tôi cũng nên đề cập rằng Mức độ song song tối đa được đặt thành 1, vì khối lượng công việc của Dynamics AX thường là OLTP và việc thay đổi nó 8 không tạo ra nhiều khác biệt trong các chỉ số chờ đợi ở trên, chúng gần như giống hệt nhau vấn đề hiệu suất.

Tôi không biết mình sẽ đi đâu từ đây, về cơ bản tôi có một Máy chủ SQL dường như bị trói chặt nhưng không chờ đợi trên runnable_t Nhiệm vụ hoặc IO.

Tôi biết rằng hệ thống con IO của SQL Server này không tốt lắm, vì chạy SQLIO trên ổ đĩa chứa cơ sở dữ liệu thực tế có thể dẫn đến số lượng khá thấp (nghĩ 10MB một giây đối với một số loại đọc / ghi), nói rằng, Dường như SQL không chờ đợi vì số lượng bộ nhớ trên máy chủ lưu trữ hầu hết các cơ sở dữ liệu.

Dưới đây là một số thông tin môi trường để giúp đỡ:

Môi trường sản xuất:

• Máy chủ SQL
• HP ProLian DL360p Gen8
• Intel Xeon E5-2650 0 @ 2.00GHz x 2 với tính năng siêu phân luồng (32 lõi logic)
• Bộ nhớ 184GB
• Máy chủ Windows 2012
• 2 phiên bản của SQL Server 2012 Standard (RTM, chưa được vá)
• Ổ đĩa Raid 1 279GB (15k) C: ổ đĩa, chứa cơ sở dữ liệu và hệ điều hành
• Trang tệp và TempDB trên các ổ riêng biệt, riêng biệt (trạng thái rắn)

DEV của tôi:

• Hyper-V lưu trữ máy chủ SQL và máy chủ AOS Dynamics AX 2012
• Core i7 3.4ghz với siêu phân luồng (8 lõi logic)
• Bộ nhớ 8GB
• Máy chủ Windows 2008 R2
• SSD cho toàn bộ VM.

Tôi sẽ hoan nghênh bất kỳ đầu vào trên những thứ khác để tìm kiếm.

Vì vậy, tôi đã giải quyết vấn đề này, hóa ra các tính năng quản lý năng lượng đã được kích hoạt trên máy chủ SQL của chúng tôi đang tăng tần số CPU lên xuống, nhưng không đủ nhanh để theo kịp nhu cầu nhỏ và đưa ra sự chờ đợi của SOS_Scheduler_Yield. Sau khi thay đổi nó để luôn chạy trong hiệu suất cao, vấn đề đã biến mất và bây giờ sự chờ đợi trở nên bình thường hơn (công cụ kiểu LatchIO).