Server hadr_capture_log_block AG中的AlwaysOn延迟

Question

在同步模式下有两个节点AlwaysON AG。上午(上午09:00)，我们注意到来自应用程序端的队列开始增长，在Server中存在高HADR_SYNC_COMMIT等待类型。

使用https://techcommunity.microsoft.com/t5/sql-server-blog/troubleshooting-high-hadr-sync-commit-wait-type-with-always-on/ba-p/385369一文，我们配置了主事件会话和次要事件会话，收集了10分钟的数据，然后将AlwaysOn AG更改为异步模式，问题就消失了。

以下是我们在扩展事件会话中得到的。

分析和上面的文章一样。

小学：

中学：

正如您所看到的，这里最大的延迟发生在模式2和3~ 249 ms之间的主模式hadr_capture_log_block上。

据我所知，瓶颈在“DbMgrPartner队列”中--处理时间太长了。问题是什么是根本原因？

在切换到异步模式后，perfmon中的网络度量(字节发送、字节接收)没有改变。

在perfmon小学有一个有趣的观点：

这里有3行相同的代码:字节发送到副本/秒，字节发送到传输/秒，日志字节被刷新/秒10:35 -当我们切换到异步时

这段时间的CPU消耗

前5名等待时间为5分钟：

Answer 1

问题是什么是根本原因？

目前没有足够的资料来作出这一决定。我们都没有您的数据，但是假设一个日志块花费249 us的时间(首先很有可能会被注意到)，那么从enqueue到dequeue之间就占用了很少的时间，这通常是由于线程执行和锁。

没有必要深入其中的杂草，但寻找更多信息的基本项目是每个调度程序的调度程序健康、处理器健康以及任何长的互斥/自旋锁时间。通常情况下，这是由于调度程序或一组调度程序具有高活动列表，并在可能非常关键的时候进行切换。请注意，SQL并没有真正切换上下文，Windows控制了这一点，并且有许多事情可以抢先运行中的线程并将其重新打开--即使是在执行过程中，也没有(Windows)等待的原因。

类似于在此期间过度使用的cpu，请注意，不需要100%的cpu使用才会出现问题。还请注意，超线程内核不是完整的执行单元。

最后，我们不知道这是否是一个VM，云计算，裸金属等，这显然将受到限制和幻想的项目。

对Waits

的响应

由于调度程序的产量在10:31到10:36之间，这是问题发生的时候(尽管整个15分钟都发布了，实际上)存在调度争用。这正是我上面所解释的。另外，它在VM中，所以您也要受虚拟机管理程序的支配。