0

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

我们有一个 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 会不断飙升。提前感谢您的想法。

等待统计监视器

4

2 回答 2

0

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

于 2021-12-14T14:01:01.327 回答
0

我建议你阅读 Paul Randal 的这篇文章。它解释了SOS_SCHEDULER_YIELD等待类型。出现的原因是什么SOS_SCHEDULER_YIELD？在这里阅读。

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

    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
于 2017-12-30T06:25:08.040 回答