SQL Server 高 CPU 使用率和 RESOURCE_SEMAPHORE 等待

Question

上周其中一个 SQL Server 出现问题，CPU 开始消耗超过 80%（正常为 10-30%）
这持续了大约 2 小时，直到我手动故障转移到 AG 中的辅助副本（这已经解决了问题）

问题开始：12:15
问题结束：14:15（手动 AG 故障转移后）

服务器信息：

SQL Server 2017  
32 logical processors (max DOP = 8)  
256 GB RAM (Max Server Memory = 180 GB, used 179 GB)

以下指标在问题出现之前与问题开始后没有明显变化

以下指标显着达到峰值，这对于该服务器来说并不典型（通常这些指标很低）：

查询：

当问题开始时，我没有注意到此服务器的工作负载发生变化
开发人员还确认应用程序完成了他们通常的工作并正在运行常规查询，应用程序负载没有峰值

在这个“高 CPU 使用率”问题中，CPU 的前 10 个查询看起来并不异常
即使 CPU 正常（10-30 %），我们通常也会看到前 10 条查询

问题：

问题似乎出在几个相关的存储过程中，该应用程序通常每秒运行 1-4 次，而那些通常在 50 毫秒内完成，但在问题期间，只要我检查了 sys.dm_exec_requests（也使用了exec ViewSessionsConnections 'running' https ://github.com/aleksey-vitsko/Database-Administrator-Tools/blob/master/Sessions%20-%20ViewSessionsConnections.sql），有来自 1 个应用程序的 50-70 个会话，都试图完成上述过程，而且很慢

在监视工具中按持续时间查看前 10 条查询时，前 1 条和 2 条是上述过程中的两条语句 - 它们没有消耗大量 CPU，但等待时间过长（RESOURCE_SEMAPHORE、LCK_M_IS）

通常这些在 10 毫秒或更短的时间内完成，每秒执行 1-4 次并且不会引起任何问题，现在这些开始每 1 次执行的持续时间为 4000-8000 毫秒，这就是问题所在

RESOURCE_SEMAPHORE 对于该服务器来说绝对不是典型的，但在问题期间它是最重要的等待之一（RESOURCE_SEMAPHORE - 等待授予内存的查询；2 小时内总共 135400234 毫秒；平均 4174 毫秒）

Granted Workspace Memory并且Reserved System Memory在问题期间 SQL Server 从 0 GB 飙升至 ~110 GB

问题：

您对以上有什么想法和经验？
常量 RESOURCE_SEMAPHORE 等待和内存授予挂起是否会导致 CPU 压力只是为查询分配工作区内存？因为在问题期间查看 CPU 的前 10 个查询时，CPU 数量看起来正常/正常
它怎么可能Granted Workspace Memory和Reserved Server Memory启动时给予启动的问题，即消费〜112和110 GB Max Server Memory180 GB和Database Cache Memory remained〜150 GB所有的时间？它是否过度使用内存或类似的东西？
为什么 SP 内部通常在 10 毫秒内完成几个月的语句会开始经历 RESOURCE_SEMAPHORE 等待并在 4000-8000 毫秒内完成？
如何在不手动故障转移到辅助副本的情况下以更外科手术的方式解决问题？我怎样才能使查询平静下来并将其恢复到 10 毫秒？计划需要删除，或查询重新编译等？什么是最好的方法来做到这一点并对其进行监控？
Brent Ozar First Responder Kit 或其他诊断程序 - 在性能问题期间应按哪个顺序执行，以更好地了解发生了什么？

Answer 1

您对以上有什么想法和经验？

为什么 SP 内部通常在 10 毫秒内完成几个月的语句会开始经历 RESOURCE_SEMAPHORE 等待并在 4000-8000 毫秒内完成？

错误计划造成的 CPU 压力。您应该使用Query Store跟踪和管理计划稳定性，以及调查不良计划并使用额外的索引和统计信息进行补救，可能还会对查询进行更改。

常量 RESOURCE_SEMAPHORE 等待和内存授予挂起是否会导致 CPU 压力只是为查询分配工作区内存？

不，它是相反的。糟糕的计划是资源密集型的，会导致大量内存分配和 CPU 使用。