除了操作系统资源之外，还有哪些因素会影响普通或分布式 AG 中的 log_send_rate？

Question

我在分布式 AG 设置中观察到 log_send_rate 较低。我知道 AG 使用日志流，所以我认为它不应该与数据有任何关系，但我想知道这是否与它正在传输的数据有关，而不仅仅是操作系统资源（网络、I/O）？

供考虑的基本指标：

SQL Server 2019-CU16
源 RAM 1.5 TB，48 个 CPU <> 目标 RAM 128 GB，48 个 CPU - 内存差异在这里起作用吗？
两台服务器位于同一 DC，ping 延迟<1ms。目标服务器是虚拟机。
ROBOCOPY 测试显示文件传输速率约为 100 MB/s
当高事务日志生成活动（例如索引维护或创建）发送到其他副本时 - 它以最大 20 MB/s 的速率传输（这不是预期的）。这是 log_send_queue 堆积起来的时候。
另一端的 REDO 速率良好，没有 REDO 队列堆积在那里。

在源 AG 上，我没有看到“发送到传输的字节数/秒”计数器的任何内容，因此我无法确定这是否是瓶颈。

如果我遗漏了任何我应该包含的内容，请提出建议。

Answer 1

Sean Gallardy 的帖子是深入研究这一问题的一个很好的资源：网络吞吐量歇斯底里

首先要确保您正在比较相同的事物。来自帖子：

我几乎从未见过有人以 SQL Server 将其用于 AG 流量的方式来测试其网络，正如我之前所说，每个数据库副本一个线程。

Sean 建议使用ntttcp来测量单线程、单核网络吞吐量。这样做将为您提供更好的基线来与 20 MB/s 进行比较。

如果仍然存在很大的差距需要解释，您可能需要更深入地研究延迟发生在流程中的确切位置。这是 Microsoft 支持人员撰写的一篇关于如何做到这一点的优秀文章：

从图中可以看出，将日志块传输和强化到辅助设备的过程中有很多步骤。经济放缓可能发生在任何地方。该博客文章末尾有一个免费工具的链接，该工具将为您分析扩展事件跟踪（仅供参考）。

就您提供的数据而言：

从故障转移的角度来看，目标上的内存差异并不理想（您的工作负载可以使用 1/12 的 RAM 有效运行吗？），但由于您没有看到高 REDO 队列，如果它有助于您看到的发送队列堆积起来。

副本位于同一个 DC 中是件好事 - 这使得整体网络延迟不太可能受到指责（您不会尝试复制到云或跨越半个地球）。

再说一次，ROBOCOPY 测试可能不是一个很好的比较。