主页 / dba / 问题 / 314840
Accepted
GAURAV RATHOD
Asked: 2022-07-26 21:32:37 +0800 CST

除操作系统资源外，什么会影响 Normal 或 Distributed AG 中的 log_send_rate？

  • 772

我在分布式 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。目标服务器是 VM。
  • ROBOCOPY 测试显示文件传输速率约为 100 MB/s
  • 当高事务日志生成活动（如索引维护或创建）被发送到其他副本时 - 它以最大 20 MB/s 的速率传输（这不是预期的）。这是 log_send_queue 堆积的时候。
  • 另一边的REDO率很好，没有REDO队列堆积在那里。

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

如果我错过了我应该包括的任何内容，请提出建议。

sql-server availability-groups

3 个回答

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

    首先要确保您正在比较等效的事物。从帖子：

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

    Sean 建议使用ntttcp来测量单线程、单核网络吞吐量。这样做会给你一个更好的基线来比较 20 MB/s。

    如果仍然需要解释一个非常大的差距，您可能需要更深入地研究延迟发生在过程中的确切位置。这是一篇来自 Microsoft 支持的优秀文章：

    同步提交 AlwaysOn 可用性组之间的数据移动延迟故障排除

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

    就您提供的数据而言：

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

    副本在同一个 DC 中是件好事——这样就不太可能归咎于整体网络延迟（您不是试图复制到云中，或者在世界的另一端）。

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

    • 6

  2. 低 SQL Server 可用性组日志发送率需要考虑的一些其他因素。

    本文针对可能导致可用性组流控制和低于预期的日志发送速率的许多情况提供了很好的描述和故障排除步骤。

    SQL AG 数据同步延迟的常见原因和故障排除解决方案

    如果可用性组是同步的，则默认禁用发送前压缩（节省一点时间和一点 CPU，使用更多带宽）。如果可用性组是异步的，则默认启用发送前压缩（需要更多时间，使用更多 CPU 以减少带宽需求）。对于给定的工作负载，折衷可能不会顺利进行。跟踪标志可用于在同步和异步可用性组发送之前覆盖默认的压缩状态。

    可用性组压缩的跟踪标志

    对于 SQL Server 虚拟机，我总是建议增加网络适配器的 TCP 接收缓冲区。如果这是一个 VMware VM，我强烈推荐 vmxnet3 网络适配器。对于 VM 中的每个 vmxnet3 适配器，当参数“small rx buffers”和“rx ring #1 size”从默认值增加到最大值时，vm 内 vRAM 使用的净差异小于 18 mb。（如果“Jumbo Packet”参数的值是“Standard 1500”或任何接近 1500 的值（如 1512），这些是要更改的参数。如果“Jumbo Packet”是 80​​00，则必须找到要修改的巨型数据包 TCP 接收参数。）在这种情况下在可用性组中，确保辅助服务器上有足够的 TCP 接收资源可以减少传输过程中由于数据包丢失而导致的传输速度下降。

    在 ESXi 中使用 VMXNET3 的来宾操作系统中出现大量数据包丢失 (2039495)

    确保电源计划在可用性组的发送和接收端具有高性能。对于 VM 次要目标，可能需要在 VM 和主机级别进行验证。对于较旧的处理器，如果插槽上少于一半的核心处于忙碌状态，则插槽上的所有核心都可能会变慢（而不是像后来的处理器中那样对单个核心进行功率调整）。当核心速度变慢时，网络适配器等其他组件也会变慢（甚至内存访问时间也会因某些电源计划实施而变慢）。

    最后，虽然日志发送速率低于预期，但对于该工作负载，它可能处于峰值。由于压力，许多站点在可用性组中尽可能避免大型索引重建，而是专注于索引重组。

    • 4
  3. Best Answer

    非常感谢@sqL_handLe 和@Josh Darnell 对此的评论。

    但此特定问题的实际原因是源 (512) 和目标 (4096) 上的字节扇区大小不匹配。

    在使用aglatency-report-tool检查 AG 的哪个阶段正在减慢进程时（因为对于分布式 AG，我无法从 SSMS 生成延迟报告），我认为它在目的地而不是源头！

    AGLatencyReportBefore

    检查目标上的错误日志，它充满了 IO 未对齐的错误。（我知道我应该早点看这个：P）

    "有 43983616 个未对齐的日志 IO 需要回退到同步 IO。当前 IO 位于文件 F:\Log\mydb_log.ldf。 "

    根据这篇文章- 这可能意味着

    此消息是什么意思？

    SQL Server 存储引擎逻辑检测磁盘扇区大小并将对齐事务日志文件元数据和内部边界以匹配扇区大小（512 或 4096 字节）。当 SQL Server 检测到已写入日志条目并假设扇区大小与在当前 SQL Server 实例上找到的扇区大小不同时，将生成错误消息 9012。这可能发生在以下场景中：

    1. 日志从具有一个磁盘扇区大小的生产服务器传送到具有更大扇区大小的 DR 服务器

    2. 从具有一个磁盘扇区大小的服务器到具有更大扇区大小的 DR 服务器的 AlwaysOn 或数据库镜像

    3. 在创建事务日志的服务器上添加 4K 本机 SSD 卡来保存事务日志时，具有 512 扇区大小的传统 SAN 磁盘

    为了确保一致性，SQL Server 可能会从执行异步 IO 切换到同步 IO。如果使用同步 AlwaysOn 或镜像等技术，这可能会对性能产生不利影响。

    在这种情况下，AlwaysOn 副本或 DBM 辅助节点上的日志写入可能会切换到同步 IO。这可能导致主节点和副本/辅助节点之间的复制延迟高于预期

    因此，我从文章（MS 技术社区和KB3009974）中获得了一些帮助，以得出将 TF 1800 添加到源的启动参数、重新启动 SQL 服务和 log_send_rate 刚刚提升到 200 MB/s 的结论。

    AGLatencyReportAfter

    当然，您提到的几点对我找到问题的根本原因非常有帮助，我对此表示感谢！

    • 3

相关问题