可用性组的 SOS_SCHEDULER_YIELD 峰值答案

【问题标题】：SOS_SCHEDULER_YIELD spike on Availability Group可用性组的 SOS_SCHEDULER_YIELD 峰值
【发布时间】：2017-12-28 20:11:51
【问题描述】：

我快要在这件事上失去理智了。

我们有一个 3 服务器可用性组，我们的应用程序从该组中读取所有 3 台服务器。 99.9% 的时间运行良好。我们时不时地在 SOS_SCHEDULER_YIELD 中得到一个峰值。当这种情况发生时，我们的很多查询都会超时。通常不会持续超过一分钟。我们有一个任务每 2 分钟捕获一次等待统计信息（下图）。

8a 是可用性组中的主服务器。如您所见，SOS_SCHEDULER_YIELD 从 10:40 的 122,000 飙升至 10:42 的 4,000,000 并在 10:44 回升至 85,000。其他服务器飙升至 2,000,000 左右。

这些服务器都是虚拟的。 8a 和 8c 位于同一主机上，而 8b 位于不同的本地数据中心。服务器使用它们所在的数据中心中的 SAN，因此 8a 和 8c 使用相同的 SAN。

当时没有作业在运行。服务器管理员在服务器本身上没有发现任何问题。 8b CPU 使用率的主机从 10:40 的 43% 飙升至 1045 的 70%，另外 2 台的主机同时从 42% 飙升至 62%。两者都在 10:50 时回落。

我需要了解可能导致此类行为的原因和/或有关如何排除故障的想法。我了解 SOS_SCHEDULER_YIELD 可能是一个指标，而不是问题本身。我只知道，当我开始在这些服务器上超时时，SOS_SCHEDULER_YIELD 会不断飙升。提前感谢您的想法。

【问题讨论】：

我会调查 CPU 峰值的原因。 SOS_SCHEDULER_YIELD 等待是其副产品。可能是并行查询（也会有 CXPACKET 等待），甚至可能是 SQL Server 进程之外的东西。
这是我的问题。我想不通。直到一切恢复正常后，我们才会收到通知。我不确切知道正在运行什么查询。这只会持续大约 1 分钟，而且我们没有实时监控工具。
考虑创建一个 XE 跟踪来捕获长时间运行的批处理和 rpc 完成的事件以进行取证。
我通常会要求公司投资这些 24/7 监控工具，这使我们作为 DBA 的工作变得容易得多，但是当监控工具不是一个选项时，使用sp_WhoIsActive 很方便，我通常设置一个作业以在服务器上每 10 秒捕获一次 sp_whoIsActive。如果由于任何原因无法 24/7 运行它，请仅在您认为有问题的时间窗口内运行它，您将了解更多关于您的服务器的信息，有些事情可能会让您感到惊讶 :)
我们每分钟运行一个版本。问题是当 CPU 峰值查询超时时。其中包括 sp_WhoIsActive。我也想不出 AG 中所有 3 台主机上的 CPU 同时出现峰值的原因。真的很奇怪。

标签： sql-server sql-server-2016 availability-group

【解决方案1】：

我建议你 read this article Paul Randal。它解释了SOS_SCHEDULER_YIELD 等待类型。是什么导致SOS_SCHEDULER_YIELD 出现？阅读here。

在 1042am 左右，尝试执行下面的查询。从那里检查查询和查询计划并从那里进行分析。

    SELECT
    [er].[session_id],
    [es].[program_name],
    [est].text,
    [er].[database_id],
    [eqp].[query_plan],
    [er].[cpu_time]
FROM sys.dm_exec_requests [er]
INNER JOIN sys.dm_exec_sessions [es] ON
    [es].[session_id] = [er].[session_id]
OUTER APPLY sys.dm_exec_sql_text ([er].[sql_handle]) [est]
OUTER APPLY sys.dm_exec_query_plan ([er].[plan_handle]) [eqp]
WHERE
    [es].[is_user_process] = 1
    AND [er].[last_Wait_type] = N'SOS_SCHEDULER_YIELD'
ORDER BY
    [er].[session_id];
GO

【讨论】：

我很想这样做，但我不知道什么时候会再次发生，所以很难做到。

【解决方案2】：

我们今天也遇到了同样的情况，这是由于虚拟化问题。我们在同一物理主机上有另一个虚拟机，它的 CPU 飙升至 100%，由于过度使用和缺少预留，我们使用了数据库虚拟机。我认为这几乎不可能从数据库/数据库虚拟机中追踪。 SOS_SCHEDULER_YIELD 等待实际上是整个 VM 等待或 CPU 周期。

【讨论】：