CMEMTHREAD 在可用性组中的索引优化期间等待

Question

在 3 节点可用性组中，由于 Microsoft 文档中涵盖的原因，辅助副本通常会受到重做延迟的影响：

故障排除：主副本上的更改未反映在辅助副本上

根据我的经验，我最常看到的问题似乎是：

主要副本上长时间运行的事务会阻止在次要副本上读取更新。

和

辅助副本上的重做线程被长时间运行的只读查询阻止进行数据定义语言 (DDL) 更改。重做线程必须先解除阻塞，然后才能为读取工作负载提供进一步的更新。

我可以通过查看扩展事件会话“AlwayOn Health”来观察这一点：

当应用程序向辅助副本发出只读查询时，如果在主副本上运行大量记录的操作（如索引优化），同步滞后变得明显，并且我看到辅助副本上未提交的日志记录中有大量积压，如所述在上面的 MS 文档中。

我的问题是为什么我看到 CMEMTHREAD 在主副本上进行索引重组时在辅助副本上等待：

这是正常/预期的行为还是其他什么？

虽然辅助副本上有一些读取活动，但这些查询在运行时通常<1 秒，偶尔<10 秒查询。CPU 使用率在 5% 左右。

Output of @@VERSION: Microsoft SQL Server 2016 (SP1-CU10-GDR) (KB4293808) - 
13.0.4522.0 (X64)   Jul 17 2018 22:41:29   Copyright (c) Microsoft Corporation  
Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2012 R2 
Standard 6.3 <X64> (Build 9600: ) (Hypervisor) 

• 仅在辅助副本上观察到 CMEMTHREAD 等待
• 显示此等待（和滞后）的副本是主动查询的同步副本

更新：我刚刚发现在索引优化期间再次发生此 WAIT。我终止了索引作业，然后显然停止了同步延迟的增加，但是 CMEMTHREAD 等待继续并且重做似乎很慢。我还注意到偶尔 PARALLEL_REDO_FLOW_CONTROL 在重做线程上等待，所以我只是简单地执行，DBCC TRACEON (3459, -1)然后重做速度突然增加，积压开始非常快地清除。

您可以看到我在下午 1:20 停止索引优化并在下午 1:45 应用跟踪标志。请注意，SQLSentryOne 等待图采用 UTC，而后一个图采用 BST。

• 更新

我刚刚在一个ASYNC没有运行任何东西的副本上再次观察到这种确切的行为。相同的跟踪标志再次解决了这个问题。我很惊讶，因为我原以为这是由只读查询引起的，导致SYNC主服务器上发生大量日志操作（如索引维护）的副本争用。在这种情况下，我们在主节点上进行索引维护，一个SYNC没有重做问题的ASYNC副本，但一个有这个问题的副本。在这里，您可以看到WAIT显示 CMEMTHREAD的统计信息以及启用跟踪标志、CMEMTHREAD 等待消失且重做争用已解决的点。

Answer 1

我无法访问真正有用的辅助可用性组:-)

但我可以分享一些能让你走得更远的事情。

当您在辅助服务器上进行并行重做时，诸如重做索引维护之类的活动会伴随着 CMEMTHREAD 等待。当全局启用跟踪标志 3459 时，这些等待就会消失。您想知道 CMEMTHREAD 等待行为是否是由于错误造成的。

CMEMTHREAD 等待行为不太可能是由于错误造成的。

下面链接的帖子已有几年历史，但仍然是我最喜欢解释 CMEMTHREAD 等待内存对象序列化控制的意图的帖子。Bob 解释说，那些可能由 CMEMTHREAD 等待控制访问的内存对象可能是全局的、按 NUMA 节点分区或按 CPU 分区。

工作原理：CMemThread 和调试 Bob Dorr 和 Rohit Nayak 2012 年 12 月 20 日 https://techcommunity.microsoft.com/t5/sql-server-support/how-it-works-cmemthread-and-debugging-them/ba- p/317488

SQL Server 2016 的重要增强之一是引入了动态内存对象分区。在 SQL Server 2016 之前，由于观察到争用是各个全局内存对象上的一个重大问题，因此各个跟踪标志将启用按 NUMA 节点对该对象进行分区（跟踪标志 1236 是一个示例）。跟踪标志 8048 会将许多在 NUMA 节点级别分区的内存对象提升为在 CPU 级别分区。

在 SQL Server 2016 中，许多内存对象都符合动态对象分区的条件：它们从单个全局分区开始，但当检测到争用时，它们将被提升为 NUMA 节点分区。如果检测到进一步的争用，该对象将再次提升为 CPU 分区。

这篇博文中有更多相关内容。

动态内存对象缩放 Ajay Jagannathan 2016 年 6 月 27 日 https://techcommunity.microsoft.com/t5/sql-server/dynamic-memory-object-scaling/ba-p/384755

因此，虽然并行重做活动的 CMEMTHREAD 等待时间较长，但随着时间的推移观察下面的查询结果将揭示哪些内存对象处于争用状态。我认为它可能是一个不符合动态分区条件的全局对象。

SELECT omo.type, memory_node_id, omo.pages_in_bytes, omo.partition_type, omo.partition_type_desc, 
omo.waiting_tasks_count, omo.exclusive_access_count, omo.contention_factor
FROM sys.dm_os_memory_objects omo
WHERE omo.waiting_tasks_count > 0
ORDER BY omo.waiting_tasks_count DESC;

因此，启用全局跟踪标志 3459 可缩短 CMEMTHREAD 等待时间。在这种情况下，这是可以预料的。全局跟踪标志 3459 禁用并行重做，使 AG 成为辅助串行重做。通过用于可用性组辅助重做活动的单个重做线程，并行重做中存在的内存对象的争用突然消失了。

无论在这种情况下哪个内存对象受到争用，都可以进行增强以允许它像许多其他对象一样动态提升，这将减轻 CMEMTHREAD 等待，即使使用并行重做也是如此。但某些工作的分区比作为单个全局对象完成更困难或更昂贵。