SOS_SCHEDULER_YIELD 等待问题排查

Question

运行我们的企业 ERP (Dynamics AX 2012)，我注意到我们的生产环境似乎比我们的开发系统慢得多。

在运行跟踪的同时在开发和生产环境中执行相同的活动后，我确认与开发相比，SQL 查询在我们的生产环境中的执行速度非常慢（平均慢 10-50 倍）。

起初我将此归因于负载，并在下班时间在生产环境上重新运行相同的活动，并在跟踪中发现相同的结果。

我清除了 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，我搜索了一下，发现它通常与 CPU 无法跟上。

然后我连续多次运行这个查询。

SELECT *
FROM sys.dm_os_schedulers
WHERE scheduler_id < 255

我知道我应该寻找具有非零 runnable_tasks_count 或 pending_disk_io_count 的调度程序，但它几乎一直都是零。

我还应该提到，最大并行度设置为 1，因为 Dynamics AX 工作负载本质上通常是 OLTP，并且将其更改为 8 对上述等待统计数据没有太大影响，它们变得几乎完全相同性能问题。

我有点不知所措，我基本上有一个看似 CPU 受限但不等待 runnable_tasks 或 IO 的 SQL Server。

我确实知道这个 SQL Server 的 IO 子系统不是很好，因为在包含实际数据库的驱动器上运行 SQLIO 可能会导致非常低的数字（对于某些类型的读/写，每秒 10MB），也就是说，由于服务器上缓存大多数数据库的内存量，SQL 似乎没有等待。

以下是一些可以提供帮助的环境信息：

生产环境：

• 数据库服务器
• HP ProLian DL360p Gen8
• Intel Xeon E5-2650 0 @ 2.00GHz x 2 带超线程（32 个逻辑内核）
• 184GB内存
• 视窗服务器 2012
• 2 个 SQL Server 2012 Standard 实例（RTM，未修补）
• Raid 1 279GB 驱动器 (15k) C: 驱动器，包含数据库和操作系统
• 页面文件和 TempDB 位于不同的独立驱动器（固态）上

我的开发者：

• Hyper-V 托管的 SQL Server 和 Dynamics AX 2012 AOS 服务器
• Core i7 3.4ghz 带超线程（8 个逻辑核心）
• 8GB 内存
• 视窗服务器 2008 R2
• 整个 VM 的 SSD。

我欢迎任何关于其他事情的意见。

Answer 1

所以我解决了这个问题，结果是在我们的 SQL 服务器上启用了电源管理功能，这些功能正在上下调整 CPU 频率，但速度不够快，无法跟上小需求，并引入了 SOS_Scheduler_Yield 等待。将其更改为始终以高性能运行后，问题消失了，现在等待更加正常（LatchIO 类型的东西）。