Quincy 中的 QoS：mClock 和 WPQ 调度器与后台操作的比较 - 第 1 部分

简介 ¶

本比较研究是对 研究 的后续，该研究测试了 mClock，当时客户端操作正在进行，并且仅有恢复/回填操作在后台运行。本研究的目标是优化现有 mClock 配置中后台尽力服务类操作的 QoS 参数。为此，针对包括 scrub 和 snaptrim 等操作的尽力服务类操作的 QoS 参数进行了优化测试。 本博客的第一部分讨论了所使用的方法，并展示了使用优化 QoS 参数进行 snaptrim 和恢复操作的测试结果，这些参数效果良好。

此外，在博客的结尾，展示了在逻辑上扩展的集群上测试 mClock 以及客户端操作和恢复/回填操作的结果。

概述 ¶

对于每个调度器，测试涉及在 RBD 池上运行客户端操作，同时在后台进行以下操作

• 测试 A：在单独的池上进行 Snaptrim 操作
• 测试 B：在单独的池上并行进行后台恢复和 snaptrim 操作。

将结果汇总，并比较了以下操作类型的两个调度器之间的以下统计信息

• 外部客户端
  • 平均吞吐量 (IOPS)
  • 平均完成时间和百分位数 (95%、99%、99.5%) 延迟
• 后台恢复
  • 平均恢复吞吐量
  • 每秒恢复的错位对象数
• 后台 snaptrim
  • 平均 snaptrim 速率
  • 修剪的对象数

测试环境 ¶

用于测试的单个节点配置如下

• 软件配置：CentOS 8.1.1911 Linux Kernel 4.18.0-193.6.3.el8_2.x86_64
• CPU：2 x Intel® Xeon® CPU E5-2650 v3 @ 2.30GHz
• nproc: 40
• 系统内存：64 GiB
• Tuned-adm Profile：network-latency
• Ceph 版本：17.0.0-12483-g307e20ec647 (307e20ec64724620831e1c3f0ad806562c80592a) quincy (dev)
• 存储：Intel® NVMe SSD DC P3700 Series (SSDPE2MD800G4) [4 x 800GB]

所有 Ceph 池都配置了复制因子 3。在该节点上配置了总共 4 个 OSD 用于测试。

测试方法 ¶

Ceph cbt 用于测试场景。创建了一个新的测试来生成后台 snaptrim 操作和与客户端 I/O 并行进行的恢复操作。首先使用加权优先级队列 (WPQ) 调度器执行该测试 3 次。这提供了一个用于比较的基线。

之后，使用 mClock 调度器和不同的 mClock 配置（即high_client_ops、balanced 和 high_recovery_ops）执行相同的测试。汇总结果进行比较。对于每个 mClock 配置，该测试执行 3 次，并且在本研究中报告这些运行的平均值。

建立基线客户端吞吐量 (IOPS) ¶

对于测试，NVMe SSD 被用作 OSD 的后端设备。设置了 OSD 到设备的 1:1 映射。但在实际测试之前，通过在配置了相同 OSD 的单个 RBD 池上运行 100% 4KiB 随机写入 ‘fio’ 基准测试，并使用复制因子 3，建立了基线吞吐量。 建立了大约 23K IOPS (91 MiB/s) @ 4KiB 随机写入的平均基线客户端吞吐量。 使用这些 步骤 确定 bluestore 节流参数，即 bluestore_throttle_bytes 和 bluestore_throttle_deferred_bytes 为 256 KiB（请注意，使用了 ‘fio’ 工具而不是 OSD 基准测试）。

OSD 容量确定留给自动化过程。这代表单个 OSD 的原始容量，通常较高。mClock 配置在 OSD 中为每个服务级别（客户端、恢复和其他后台操作）计算 QoS 分配时使用此容量。

mClock 配置分配 ¶

下表显示了每个配置文件的低级别 mClock 分配。对于保留和限制等参数，分配表示为原始 OSD 容量的百分比。例如，在high_client_ops配置文件中，保留参数设置为原始 OSD 容量的 50%。启用配置文件后，将在后台进行这些分配。权重参数是无单位的。有关 mClock QoS 参数的更多详细信息，请参阅 基于 mClock 的 QoS。

为了测试，在到达以下表中概述的值之前，对“后台尽力服务”客户端的配置文件分配进行了大量的实验。

配置文件 - high_client_ops (默认) ¶

与恢复和 Ceph 内部的其他操作相比，此配置文件为外部客户端操作分配更多的保留和限制。默认情况下启用此配置文件。

配置文件 - high_recovery_ops ¶

与外部客户端和 Ceph 内部的其他操作相比，此配置文件为恢复操作分配更多的保留。例如，管理员可以在非高峰时段临时启用此配置文件以加快后台恢复速度。

配置文件 - 平衡 ¶

此配置文件为客户端操作和后台恢复操作分配相等的保留。内部尽力服务客户端获得略低的保留和 50% 的限制，以便在没有竞争服务的情况下也能快速完成。

mClock 配置参数 ¶

mClock 相关的配置选项在透明地选择任何内置配置文件时设置。有关配置文件覆盖哪些配置选项的更多信息，请参阅标题为 mClock 内置配置文件 的部分。

其他 Ceph 配置参数 ¶

重要的是要注意 mClock 配置文件覆盖的以下 Ceph 恢复相关选项

• osd_max_backfills = 1000
• osd_recovery_max_active = 1000

上述选项设置了每个 OSD 上本地和远程回填/恢复操作的并发数量的上限。在这些条件下，测试了 mClock 调度器的功能，结果如下所示。

未更改的与 snaptrim 相关的 Ceph 配置选项如下所示

• osd_pg_max_concurrent_snap_trims = 2
• osd_snap_trim_cost = 1048576

客户端操作与后台 Snaptrim 操作 ¶

测试步骤 ¶

1. 启动具有 4 个 osd 的 Ceph 集群。
2. 禁用 pg 自动缩放器和 scrub。
3. 创建一个客户端 RBD 池，复制因子为 3，并在其中预填充一些对象。
4. 创建一个具有复制因子 3 的 RADOS snap 池。
5. 用 100K 4MiB 大小的对象预填充 snap 池。
6. 创建 snap 池的 RADOS 池快照。
7. 覆盖 snap 池中 80% 的对象。这创建了 80K 克隆对象。
8. 使用 fio 在 300 秒内启动客户端池上的 I/O
9. 在客户端 I/O 稳定 30 秒后，删除在步骤 6 中创建的快照。这将触发 snaptrim 操作中删除 80K 克隆对象。
10. 在步骤 9 上面，捕获与客户端延迟和吞吐量相关的统计信息。该测试还捕获修剪 80K 对象所花费的时间。

总而言之，测试期间创建了 2 个池。Snaptrim 在一个池上触发，客户端 I/O 同时在另一个池上触发。捕获的测试统计信息讨论如下。

测试结果 ¶

客户端吞吐量比较 ¶

下图显示了跨调度器及其各自配置的平均客户端吞吐量比较。使用 fio 在客户端 RBD 池上使用 4KiB randrw 确定了两个调度器的平均基线吞吐量略高于 23K IOPS。

显示的客户端吞吐量是 fio 在测试过程中（300 秒）报告的平均吞吐量。重要的是要注意 snaptrim 持续时间是客户端 I/O 运行时间的一个子集。

使用默认 Ceph 配置的 WPQ 调度器的平均客户端吞吐量为 17520.63 IOPS，比基线 (WPQ) 吞吐量低近 25%。但是，使用 mClock 调度器和默认high_client_ops配置文件，与 WPQ 调度器相比，平均客户端吞吐量几乎高 10%，为 19217.59 IOPS。这满足了 mClock 配置中客户端操作设置的 50% 最小保留标准。

该图还显示了其他 mClock 配置报告的整体客户端吞吐量。由于其他 mClock 配置中分配给客户端操作的保留较低，因此预计客户端吞吐量较低。使用balanced配置文件，获得的平均吞吐量为 18998.55 IOPS（比 WPQ 高 8.4%）。使用high_recovery_ops配置文件，为 18293.20 IOPS（比 WPQ 高 4.4%）。

这表明 mClock 能够在后台 snaptrim 操作进行中提供客户端所需的 QoS。与 WPQ 调度器相比，mClock 配置的平均客户端吞吐量更高。

客户端延迟比较 ¶

下图 2 显示了 WPQ 调度器和 mClock 调度器配置之间的平均完成延迟 (clat) 以及平均 95%、99% 和 99.5% 百分位数。此外，还显示了 snaptrim 操作活动期间观察到的平均 clat 的更准确的度量。这表示为图中的clat (snaptrim)。这显示了 mClock 配置相对于 WPQ 调度器在提供相对相似的平均客户端延迟，但 snaptrim 速率不同的方面的有效性。显着差异在于百分位数延迟 [95%、99%、99.5%], 其中high_client_ops显示最低延迟，如预期。

使用 WPQ 获得的整体平均客户端完成延迟为 3.280 毫秒。但是，在 snaptrim 阶段，平均客户端完成延迟为 6.2 毫秒，与基线值 2.747 毫秒相比增加了近 126%！

使用 mClock high_client_ops配置文件，整体平均完成延迟略高，为 3.323 毫秒。但 snaptrim 阶段，平均完成延迟为 4.506 毫秒，比 WPQ 观察到的低 27% 以上。下表显示了 WPQ 和 mClock 调度器之间的延迟比较。

使用其他配置文件，如balanced和high_recovery_ops，整体平均客户端完成延迟略微增加到 3.364 毫秒和 3.506 毫秒。在 snaptrim 阶段，使用balanced配置文件，平均 clat 为 5.074 毫秒，比 WPQ 调度器观察到的低 18%。使用high_recovery_ops配置文件，为 5.270 毫秒，比 WPQ 调度器观察到的低约 15%。

图 3 和图 4 显示了在几次测试运行中，WPQ 和 mClock 配置之间的平均客户端延迟变化的比较。这些图表跟踪 snaptrim 操作期间平均客户端完成延迟受到的影响。

可以看到两个图表中的延迟在客户端 I/O 开始后 30 秒增加，此时触发了 snaptrim 操作。虽然 mClock 配置中存在中间延迟峰值，但它们主要低于 WPQ 延迟配置文件。

因此，可以得出结论，mClock 调度器能够在 snaptrim 操作期间为客户端操作提供显著更高的吞吐量和更低的延迟。但是，这是否会对 snaptrim 速率和持续时间产生影响？下一节将对此进行分析。

Snaptrim 速率比较 ¶

另一个重要的指标是 mClock 配置对 snaptrim 速率和时间的影响，以及它们与 WPQ 调度器的比较。

图 5 显示，使用 WPQ 调度器，平均 snaptrim 速率为 671 个对象/秒，对于 80K 个对象，平均 snaptrim 持续时间为 121.83 秒。

使用 mClock high_client_ops 配置，对于修剪相同数量的对象，平均 snaptrim 速率为 747 个对象/秒，平均 snaptrim 持续时间为 111.34 秒。这意味着 mClock 调度器平均能够快 8.6% 完成 snaptrim 操作，并且与 WPQ 调度器相比，平均延迟降低了 27%！这可以归因于该配置中为最佳努力类分配了 25% 的 OSD 容量的最高保留量，其中包括 snaptrim 操作。

使用 mClock balanced 配置，平均 snaptrim 速率最高，接近 804 个对象/秒，相应的平均 snaptrim 持续时间为 100 秒。这可以归因于为 snaptrim 操作分配的 OSD 容量最高限制为 50%。在这种情况下，mClock 调度器平均能够快近 18% 完成 snaptrim 操作，并且与 WPQ 调度器相比，平均延迟降低了 20%！high_recovery_ops 配置中的数值介于两者之间，snaptrim 速率为 766 个对象/秒，平均 snaptrim 持续时间为 108 秒。这再次可以归因于最佳努力保留量 (10%) 和限制量 (40%) 的设置。

另一个有趣的图表是 WPQ 调度器的 snaptrim 速率与 mClock 调度器配置的比较。图 6 和图 7 中的图表显示了对几次测试运行随时间推移的比较。这些图表清楚地显示，high_client_ops 配置的 snaptrim 速率最初进展速度慢于 WPQ 调度器和其他 mClock 配置。在经过一半的时间后，high_client_ops 配置的 snaptrim 速率超过了 WPQ 速率。

这些图表还显示，balanced 和 high_recovery_ops 配置的 snaptrim 速率进展速度快于 high_client_ops 配置。如前所述，这可以归因于为 snaptrim 操作分配的更高限制，以及因为没有像恢复、擦洗和其他后台操作这样的竞争操作。

Snaptrim 对客户端延迟的影响 ¶

为了更好地了解 snaptrim 操作对客户端延迟的影响，下面的图表将客户端延迟配置文件与 snaptrim 速率叠加在一起。这显示了 snaptrim 阶段期间的客户端延迟变化。

这些图表在实验阶段很有用，可以确定最佳努力操作的保留量、权重和限制分配，并验证分配是否会对客户端操作产生负面影响，并帮助对配置文件进行增量更改。

上面的图表展示了 WPQ 调度器和 high_client_ops mClock 配置之间 snaptrim 阶段期间客户端延迟如何变化的一个例子。很容易看出，使用 high_client_ops 时，延迟峰值和变化的幅度远低于 WPQ 调度器。

客户端操作与 Snaptrim & 恢复操作 ¶

测试步骤 ¶

1. 启动具有 4 个 osd 的 Ceph 集群。
2. 禁用 pg 自动缩放器和 scrub。
3. 创建一个客户端 RBD 池，复制因子为 3，并在其中预填充一些对象。
4. 创建一个复制因子为 3 的 RBD 恢复池。
5. 标记一个 OSD 离线。在集群处理 OSD 离线事件后，将 30K 4MiB 对象预填充到恢复池中。
6. 创建一个具有复制因子 3 的 RADOS snap 池。
7. 暂时禁用恢复和回填操作。
8. 启动步骤 5 中关闭的 OSD
9. 将 70K 4MiB 大小的对象预填充到 snap 池中。
10. 创建 snap 池的 RADOS 池快照。
11. 覆盖 snap 池中的 100% 对象。这将创建 70K 个克隆对象。
12. 使用 fio 在 300 秒内启动客户端池上的 I/O
13. 在客户端 I/O 稳定 30 秒后，删除步骤 10 中创建的快照。这将触发作为 snaptrim 操作的一部分删除 70K 个克隆对象。
14. 同时，启用恢复和回填操作（在步骤 7 中禁用）。这将触发错误放置对象的回填。
15. 捕获与客户端延迟和吞吐量相关的统计信息。该测试还捕获了修剪 70K 个对象所花费的时间以及恢复所有错误放置对象所花费的时间。

总而言之，上述步骤在测试期间创建 3 个池。Snaptrim、恢复和客户端操作同时在单独的池上触发。捕获的测试统计信息如下讨论。

测试结果 ¶

客户端吞吐量比较 ¶

图 9 显示了跨调度器及其各自配置的平均客户端吞吐量比较。使用 fio 在客户端 RBD 池上，确定两种调度器的平均基线吞吐量约为 23K IOPS（4KiB randrw）。

显示的客户端吞吐量是测试过程中 fio 报告的平均吞吐量。重要的是要注意，恢复/回填和 snaptrim 持续时间构成了客户端 I/O 运行时间的一个子集。

使用默认 Ceph 配置的 WPQ 调度器的平均客户端吞吐量为 12939.71 IOPS，比基线（WPQ）吞吐量低 43%。但是，使用 mClock 调度器和默认 high_client_ops 配置，平均客户端吞吐量比 WPQ 调度器看到的平均吞吐量高约 5.5%，为 13651.66 IOPS。这满足了 mClock 配置中为客户端操作设置的 50% 的最低保留标准。

该图表还显示了其他 mClock 配置报告的总体客户端吞吐量。由于其他 mClock 配置中为客户端操作分配的保留量较低，并且后台恢复和 snaptrim 处于活动状态，因此预计客户端的吞吐量会显著降低。因此，使用 balanced 配置，获得了平均吞吐量 10541.26 IOPS。这是基线（mClock）吞吐量的 45%。最后，使用 high_recovery_ops 配置，为 9168.12 IOPS，约为基线（mClock）吞吐量的 39%。这表明 mClock 配置正在满足最低保留标准。

这表明 mClock 能够在后台 snaptrim 和恢复操作进行时为客户端提供所需的 QoS。

客户端延迟比较 ¶

下图表显示了平均完成延迟（clat）以及 WPQ 调度器和 mClock 调度器配置的平均第 95、99 和 99.5 百分位数。此外，还显示了 snaptrim 和恢复操作处于活动状态期间观察到的平均 clat 的更准确的度量值。这表示为图表中的 clat (trim+rec)。这显示了 mClock 配置相对于 WPQ 调度器的有效性。

使用 WPQ 获得的总体平均客户端完成延迟为 4.945 毫秒。但是，在 snaptrim 阶段，平均客户端完成延迟为 7.385 毫秒，与基线值 2.805 毫秒相比增加了超过 163%！

使用 mClock high_client_ops 配置，总体平均完成延迟略低，为 4.677 毫秒。但是，在 snaptrim 和恢复阶段，平均完成延迟为 8.02 毫秒，比 WPQ 调度器高 8.6%。这可以归因于为 snaptrim 操作分配的更高带宽。

使用其他配置，如 balanced 和 high_recovery_ops，总体平均客户端完成延迟显著增加到 6.118 毫秒和 6.998 毫秒。在 snaptrim 和恢复阶段，平均 clat 更高，与 WPQ 调度器相比，范围在 11% 到 34% 之间，如表中所示。正如预期的那样，这是由于这些配置中为恢复和 snaptrim 操作设置的更高限制。

在下面的测试运行期间，显示了 snaptrim 和恢复操作期间平均客户端延迟变化的比较。这跟踪了后台操作的不同点对平均客户端完成延迟的影响。

可以看到，high_client_ops 的延迟在后台操作在客户端 I/O 开始后 30 秒内启动时最初会增加。初始延迟高于 WPQ 调度器看到的延迟，这可能是因为 mClock 配置允许更高的 snaptrim 吞吐量。最终，平均客户端延迟下降到 WPQ 以下的中期阶段，并且可以在这里清楚地看到 mClock 的好处，因为客户端操作由于高限制和权重而得到更多偏好。

Snaptrim 速率比较 ¶

mClock 配置会影响 snaptrim 速率和时间，下面的图表显示了它们与 WPQ 调度器的比较。

使用 WPQ 调度器，平均 snaptrim 速率约为 431 个对象/秒，修剪 70K 个对象所需的平均持续时间为 164.24 秒。

使用 mClock high_client_ops 配置，对于修剪相同数量的对象，平均 snaptrim 速率约为 528 个对象/秒，平均 snaptrim 持续时间为 133.59 秒。这意味着 mClock 调度器平均能够快 18.7% 完成 snaptrim 操作，并且与 WPQ 调度器相比，平均客户端延迟仅高 8.6%。这可以归因于该配置中为最佳努力类分配了 25% 的 OSD 容量的最高保留量。

使用 balanced 配置，由于较低的保留量，平均 snaptrim 吞吐量下降到约 495 个对象/秒，因此 snaptrim 持续时间也更高。同样适用于 high_recovery_ops 配置，平均 snaptrim 吞吐量最低，平均 snaptrim 持续时间最高。

图 13 中的 snaptrim 速率比较图表清楚地显示，high_client_ops 配置的 snaptrim 速率最初进展速度慢于 WPQ 调度器。在经过一半的时间后，high_client_ops 配置的 snaptrim 速率超过了 WPQ 速率。

使用其他 mClock 配置，情况有所不同，因为恢复正在并行进行。balanced 和 high_recovery_ops 配置的初始 snaptrim 速率略慢，因为保留量分配较低。由于更高的限制分配，速率略有提升，然后再次被节流，最终完成时间比 high_client_ops 配置晚得多。

恢复速率比较 ¶

该测试的另一个主要方面是分析 mClock 配置如何影响恢复操作，通过建立恢复吞吐量、恢复时间和对客户端操作的影响等指标。如下面的柱状图所示，high_client_ops 配置对恢复操作影响最大。这是预期的，因为为后台恢复分配的保留量最低。平均恢复吞吐量和时间与 WPQ 调度器看到的相似，分别为 83 个对象/秒和 224 秒。

图 15 显示了 WPQ 调度器和 mClock 配置之间的恢复速率。

如预期的那样，high_recovery_ops 配置具有最高的平均恢复吞吐量，接近 140 个对象/秒，并且恢复大约 18K 个对象的最短平均恢复时间约为 130 秒。

balanced 配置提供了一个很好的中间地带，为客户端和恢复操作分配相同的保留量和权重。恢复速率曲线介于 high_recovery_ops 和 high_client_ops 曲线之间，平均吞吐量约为 125 个对象/秒，完成恢复平均需要 144 秒。

Snaptrim + 恢复对客户端延迟的影响 ¶

为了了解 snaptrim 和恢复操作对客户端延迟的影响，下面的图表将客户端延迟配置文件与测试期间的 snaptrim 和恢复速率叠加在一起。

下面的图表提供了 snaptrim 和恢复阶段期间客户端延迟如何在 WPQ 调度器和 mClock 配置之间变化的一个了解。很容易看出，使用 high_client_ops 时，平均客户端延迟在 snaptrim 操作完成之前略高。很明显，high_client_ops 配置的 snaptrim 速率曲线比 WPQ 调度器的速率曲线更陡峭，这就是平均客户端延迟略高的原因（8.6%）。但另一方面，平均 snaptrim 速率快约 18.7%。

对于 balanced 和 high_recovery_ops 配置，可以看到恢复完成更快，这对应于 snaptrim 和客户端操作的影响。这是由于这些配置中为客户端和最佳努力操作分配的 QoS 保留和限制。

缩放集群：客户端操作和恢复 ¶

测试环境 ¶

本文的目标之一是在扩展环境中测试 mClock，以测试 mClock 配置文件的有效性并识别与扩展相关的任何问题。为此，使用了由 Cephadm 支持的大规模测试集群，称为 Gibba 集群。扩展后的集群总共有 975 个 OSD（SSD）和 40 台主机，原始容量为 13 TiB。但对于恢复测试，使用了总共 3 台主机，每台主机托管 25 个 OSD。此外，还使用了 3 个 RBD 池（1 个预先存在，包含约 1 亿个 4KiB 对象，1 个用于客户端操作的池，以及 1 个包含 100K 个 4 MiB 对象的恢复池）进行测试。所有 Ceph 池都配置了复制因子 3。为了触发错位对象的恢复，从每台主机重启一个 OSD。总而言之，在测试期间恢复了约 650K-730K 个对象，并收集了统计数据，并在 mClock 配置files之间进行了比较。使用 WPQ 调度器的测试仍在进行中，未在此博客中讨论。每个节点的配置如下所示

• 软件配置：CentOS Stream 8 Linux Kernel 4.18.0-301.1.el8.x86_64
• CPU：Intel® Xeon® E-2278G CPU @ 3.40GHz
• nproc: 16
• 系统内存：32 GiB
• Ceph 版本：quincy (dev)
• 存储：Intel® NVMe DC P4801X Series (SSDPEL1K375GA)

测试步骤 ¶

1. 在扩展集群上禁用 pg 自动缩放器和 scrub。
2. 创建一个客户端 RBD 池，复制因子为 3，并在其中预填充一些对象。
3. 创建一个复制因子为 3 的 RBD 恢复池。
4. 标记一个 OSD 宕机并移除。
5. 在集群处理 OSD 宕机事件后，将 100K 个 4MiB 对象预填充到恢复池中。
6. 启动步骤 5 中宕机的 OSD。这将触发恢复和回填操作。
7. 同时使用 fio 在客户端池上启动 500 秒的 I/O。
8. 测试会跟踪与客户端操作、恢复时间和错位对象数量相关的统计信息，以便后续分析。

测试结果 ¶

客户端吞吐量比较 ¶

确定一个 OSD 的原始吞吐量容量约为 60K IOPS（4KiB randrw）。为了减轻内存饱和及其对 OSD 节点的影响，当客户端以最大限制运行时，每个 OSD 的 osd_mclock_max_capacity_iops_ssd 设置为原始吞吐量的 ~50%，即 30K IOPS。以下讨论了来自客户端节点之一（Gibba010）的结果。

测得的平均基线吞吐量约为 ~65326 IOPS。图 20 下面显示了在客户端节点 Gibba010 上进行测试期间，mClock 配置files之间的平均客户端吞吐量比较。

正如预期的那样，high_client_ops 配置files显示了最高的吞吐量 (~64000 IOPS)，非常接近基线吞吐量。然而，high_recovery_ops (~62470 IOPS) 配置files观察到的客户端吞吐量略高于 balanced (~60350 IOPS) 配置files，考虑到配置files的预留和限制分配，这有点违反直觉。但考虑到集群的规模以及恢复操作也发生在与客户端操作不在同一 OSD 上的 PG（以及 OSD）上，可以解释这一点。如果与执行客户端操作的 OSD 上的恢复数量较少，那么客户端操作将看到更好的吞吐量和更低的延迟，如这里观察到的。在这个集群中，只有 40 台节点中的 3 台正在执行客户端操作。但主要要注意的是，客户端的 QoS 要求正在得到满足。

图 21 上面显示了测试过程中客户端的平均延迟和尾部延迟。high_client_ops 配置files显示了最低的平均延迟和尾部延迟。high_recovery_ops 配置files的平均完成延迟低于 balanced 配置files，这违反直觉，但由于前面解释的原因，这是可能的。但是，high_recovery_ops 配置files的尾部延迟（95th、99th 和 99.5th）是 mClock 配置files中最高的，这清楚地表明了 mClock 的节流效果。

恢复速率比较 ¶

本节中的图表比较了 mClock 配置files之间的恢复速率。从图 22 中的柱状图中可以看出，high_client_ops 配置files显示了最低的恢复速率，约为 ~192 个对象/秒，以及最高的恢复时间，约为 ~3825 秒，以恢复 ~730K 个对象。balanced 配置files 紧随其后，恢复速率为 ~253 个对象/秒，恢复时间为 ~2586 秒（降低 32%），以恢复 ~650K 个对象。high_recovery_ops 配置files提供了最佳的恢复性能，速率为 ~341 个对象/秒，最低的恢复时间为 ~1908 秒，以恢复 ~650K 个对象。这比 high_client_ops 配置files快 50% 以上，并且客户端完成延迟仅增加了 4.6%。这强调了 mClock 在重负载恢复下提供所需 QoS 水平的有效性。

图 23 下面的恢复速率比较进一步阐明了 mClock 配置files之间的差异，并且不言自明。

结论 ¶

这项研究的重点是利用 mClock 算法的特性，以提高外部客户端延迟和吞吐量，并为 Ceph 特定的内部操作提供可预测的 QoS。该研究试验了不同的 mClock 配置files以及 Ceph 中后台尽力服务类操作的 QoS 参数的多种排列组合。

结果表明，在适当分配 QoS 参数后，满足了恢复、snaptrim 和客户端操作所需的吞吐量和延迟要求。考虑到这项研究中进行的测试规模较小，未来仍有改进的空间。

在更大的逻辑规模下进行测试可以提供更多数据点并巩固 mClock 配置files的有效性。接下来的步骤是提出新的配置files，以满足特定要求。