Ceph Bobtail Performance – IO Scheduler Comparison
目录
简介 ¶
节假日期间最奇怪的事情之一就是我的高效率。也许是因为明尼苏达州这个时候天气非常寒冷，在外面进行的唯一娱乐活动通常包括零下冰冷的风吹在你的脸上。或者也许是经过连续的 4-5 次节日庆祝活动后，想要逃离所有其他生活形式的愿望。无论如何，这是我倾向于完成更多事情的时期（假设我没有铲 3 英尺深的雪）。幸运的是，这意味着我们已经有几篇文章在准备中了。
人们偶尔会问我，为了获得 Ceph 的最大性能，他们应该使用哪个 IO 调度器。以防你不知道，IO 调度器通常是一种算法，它使用队列或一组队列，块 IO 请求进入队列并在发送到底层存储设备之前对其进行操作。在本文中，我们将研究 Ceph 在几种不同的 Linux IO 调度器中在两种不同场景下的性能。废话不多说，让我们开始工作
在许多 Linux 系统中，通常有三种 IO 调度器可供选择。以下是每个调度器的非常简短（且不完整）的解释
- CFQ：将 IO 请求放入每个进程的队列中，并为每个队列分配时间片。
- Deadline：为 IO 请求分配截止日期，并将它们放入按截止日期排序的队列中。
- NOOP：将 IO 请求放入一个简单的 FIFO 队列中。任何调度都在另一层进行。
人们通常建议在使用 SSD 或具有回写缓存的控制器时使用 Deadline 或 NOOP。CFQ 倾向于在桌面或工作站上的旋转磁盘上表现出色，因为用户直接与系统交互。但对于 Ceph 来说，CFQ 可能没有帮助。与其仅仅根据二手知识做出推荐，我认为是时候去寻找答案并看看这些调度器的实际性能如何了。
系统设置 ¶
我们将使用 SAS2208 控制器进行这些测试。它支持 JBOD、多个单驱动 RAID0 和单 OSD RAID0 配置。不幸的是，不同的控制器将具有不同的 IO 重新排序能力，因此这些结果可能不代表其他控制器。希望它们至少能提供一个起点，并可能猜测类似配置的性能如何。
此设置中使用的硬件包括
- Chassis: Supermicro 4U 36-drive SC847A
- Motherboard: Supermicro X9DRH-7F
- 磁盘控制器：板载 SAS2208
- CPUS: 2 X Intel XEON E5-2630L (2.0GHz, 6-core)
- RAM: 8 X 4GB Supermicro ECC Registered DDR1333 (32GB total)
- Disks: 8 X 7200RPM Seagate Constellation ES 1TB Enterprise SATA
- NIC: Intel X520-DA2 10GBE
As far as software goes, these tests will use
- OS: Ubuntu 12.04
- 内核：来自 Ceph 的 GitBuilder 归档的 3.6.3
- Tools: blktrace, collectl, perf
- Ceph：Ceph “next” 分支，略早于 0.56 bobtail 版本。
测试设置 ¶
与我们之前在其他文章中所做的一样，我们正在使用 localhost TCP 套接字连接直接在 SC847a 上运行测试。我们正在执行读写测试。在每个设备的开头都设置了一个 10G 日志分区。测试了以下控制器模式
- JBOD 模式（充当标准的 SAS 控制器。不使用板载缓存。）
- 8xRAID0 模式（每个 OSD 的单个驱动 RAID0 组。使用板载回写缓存。）
- RAID0 模式（一个多磁盘 RAID0 组上的单个 OSD。使用板载回写缓存。）
为了生成结果，我们正在使用 Ceph 的值得信赖的内置基准测试命令：“RADOS bench”，它为要写入的每个数据块写入新对象（总有一天我会写上承诺的 smalliobench 文章！）。RADOS bench 具有一定的优点和缺点。一方面，它可以让你清楚地了解 OSD 在不同大小下写入和读取对象的速度有多快。它不能测试的是对大型对象执行的小 IO 的速度有多快。出于这个原因和其他原因，这些结果不一定能反映 RBD 的最终性能。
与我们之前的文章一样，我们正在运行 8 个并发的 RADOS bench 实例，并将结果汇总以确保它不会成为瓶颈。我们指示每个 RADOS bench 实例写入自己的池，每个池有 2048 个 PG。这样做是为了确保在后续的读取测试中，每个 RADOS bench 实例读取的是其他实例先前未读取到页面缓存中的唯一对象。你可能还会注意到，我们正在使用每个池的 2 的幂的 PG 数。由于 Ceph 实现 PG 分裂行为的方式，使用 2 的幂的 PG 数（尤其是在 PG 数量较低时！）可能会改善数据在 OSD 上的均匀分布。在较大的 PG 数量下，这可能不太重要。
RADOS bench 让你可以在对象大小、并发运行的数量以及测试运行时间方面进行一些灵活性。我们已经确定了以下排列的 5 分钟测试
- 4KB Objects, 16 Concurrent Operations (2 per rados bench instance)
- 4KB Objects, 256 Concurrent Operations (32 per rados bench instance)
- 128KB Objects, 16 Concurrent Operations (2 per rados bench instance)
- 128KB Objects, 256 Concurrent Operations (32 per rados bench instance)
- 4M Objects, 16 Concurrent Operations (2 per rados bench instance)
- 4M Objects, 256 Concurrent Operations (32 per rados bench instance)
对于每个排列，我们使用 BTRFS、XFS 或 EXT4 作为底层 OSD 文件系统，并使用 CFQ、Deadline 或 NOOP 作为 IO 调度器运行相同的测试。在每个测试之间重新格式化文件系统并重新运行 mkcephfs，以确保先前测试的碎片不会影响结果。请记住，如果尝试使用这些结果来确定生产集群的性能，这可能会产生误导。每个文件系统似乎以不同的方式老化，并且可能随着时间的推移表现出截然不同的性能。尽管如此，重新格式化每个测试之间对于确保比较是公平的来说是必要的。
对于这些测试，我们将大多数 Ceph 可调参数保留在默认状态，但有两个例外。“filestore xattr use omap” 已启用，以确保 EXT4 正常工作。CephX 身份验证也被禁用，因为它对于这些测试来说不是必需的。
我们确实将某些 mkfs 和挂载选项传递给底层文件系统，在有意义的情况下。响应 Bobtail 性能预览，Christoph Hellwig 指出 Ceph 可能受益于使用 inode64 挂载选项与 XFS，并提到了一些其他可能值得尝试的可调参数。我们没有时间探索所有这些，但为这些测试启用了 inode64。
- mkfs.btfs options: -l 16k -n 16k
- btrfs mount options: -o noatime
- mkfs.xfs options: -f -i size=2048 (-d su-64k, sw=8 for RAID0 tests)
- xfs 挂载选项：-o inode64,noatime
- mkfs.ext4 options: (-b 4096 -E stride=16,stripe-width=128 for RAID0 tests)
- ext4 mount options: -o noatime,user_xattr
在测试期间，collectl 用于记录各种系统性能统计信息。
4KB RADOS BENCH 写入结果 ¶
到目前为止，看起来我们的一些怀疑正在成为现实。在正在使用 WB 缓存的模式中，Deadline 和 NOOP 似乎比 CFQ 具有一些优势。这可能是因为控制器可以自己进行重新排序。但在 JBOD 模式下，情况似乎相反，CFQ 往往表现更好。
随着更多的并发操作，CFQ 在 JBOD 模式中继续表现良好。在两种 RAID 模式中，比赛已经收紧，但 CFQ 在单 OSD RAID0 配置中与 EXT4 配合使用时继续表现不佳。
4KB RADOS 基准测试读取结果 ¶
使用少量并发的 4K 读取，看起来 NOOP 和 Deadline 更适合 BTRFS，但 EXT4 和 XFS 的结果有点混乱。在 8xRAID0 模式下，CFQ 实际上可能正在领先，但应该进行更多的采样以确保这一点。
哇！这里有一些疯狂的趋势。BTRFS 性能似乎在所有 IO 调度器中都保持一致，但 XFS 和 EXT4 显示出一些很大的差异。EXT4 在单磁盘 OSD 设置中似乎比 Deadline 或 NOOP 更好地使用 CFQ。另一方面，CFQ 在 JBOD 配置中似乎比 Deadline 或 NOOP 差得多。
128KB RADOS 基准测试写入结果 ¶
使用少量并发的 128k 写入，看起来 BTRFS 倾向于选择 Deadline 和 NOOP。CFQ 似乎在 EXT4 上获得了一个孤立的胜利。但在单 OSD RAID0 配置中，XFS 和 EXT4 使用 Deadline 和 NOOP 表现更好。
添加更多的并发 128k 写入似乎将 CFQ 推回了 JBOD 测试中的领先地位。Deadline 和 NOOP 通常在具有 WB 缓存的模式下表现更好，尤其是在 EXT4 上。
128KB RADOS 基准测试读取结果 ¶
这里的结果有点混乱。我认为唯一明确的事情是，EXT4 似乎在多 OSD 模式中更喜欢 CFQ，而 BTRFS 似乎在大型 RAID0 配置中更喜欢 Deadline 和 NOOP。
随着更多的并发读取，仍然很难得出任何重大结论，除了说 EXT4 读取性能在多 OSD 配置中使用 CFQ 时仍然最高。
4MB RADOS 基准测试写入结果 ¶
很难得出任何强烈的结论，除了说 EXT4 似乎在大型 RAID0 配置中使用 Deadline 和 NOOP 表现更好。
再次，很难得出任何真正的强烈的结论，除了也许 EXT4 在 JBOD 模式下使用 CFQ 表现更好，并且在 8-OSD、单磁盘、RAID0 模式中使用 Deadline 表现最差。
4MB RADOS 基准测试读取结果 ¶
看起来 XFS 和 BTRFS 略微倾向于 Deadline 和 NOOP，而 EXT4 在多 OSD 配置中更喜欢 CFQ，但在 1-OSD RAID0 配置中更喜欢 Deadline 和 NOOP。
这里最明显的事情是在使用 EXT4 和 8-OSD RAID0 配置时，Deadline 和 NOOP 的性能急剧下降。否则，Deadline 和 NOOP 似乎可能略好于 CFQ。
RESULTS SUMMARY ¶
好吧，这不像上一篇文章那么激烈。一场比喻性的散步。尽管如此，很难从上面的散点图中得出有意义的趋势。让我们看看每个 IO 调度器的平均值，并检查它们在不同 IO 大小下的比较方式。我正在根据平均值和标准差范围的比较对结果进行颜色编码。具体来说，我采用表现出最高平均吞吐量的调度器，并将其 1 个标准差范围与表现最差的调度器的范围进行比较。如果范围重叠，则不进行颜色编码。如果范围不同，则将最高平均吞吐量调度器涂成绿色，将最低平均吞吐量调度器涂成红色。中间调度器的平均值根据其与其他两个的比较进行颜色编码。这可能不够精确用于科学期刊，但我认为对于博客文章来说，这并非完全不合理。
到目前为止，我认为我们的假设是 DEADLINE 和 NOOP 更适合具有 WB 缓存的模式大致正确。有趣的是，CFQ 在 JBOD 模式中获得了一些胜利。在 8xRAID0 模式中，有一些混合结果，但看起来唯一的重大 CFQ 胜利是针对 EXT4 读取。
结果与 4K 结果一致。CFQ 在 JBOD 模式中往往表现良好，但在其他模式下通常被 Deadline 和 NOOP 击败，除了 8xRAID0 EXT4 读取。
对于大型 IO，CFQ 似乎始终如一地获胜的唯一时间是在 JBOD 和 8xRAID0 模式下使用 EXT4。否则，如果你想优化大型 IO，最好使用 Deadline，在某些情况下是 NOOP。
结论 ¶
好了，这就是它。如果你曾经想知道使用 Ceph 时应该使用哪个 IO 调度器，希望这能提供一些见解。即，如果你使用 EXT4 或具有 JBOD 配置，CFQ 可能值得一看。在许多其他配置中，你可能希望选择 Deadline（或有时是 NOOP）。在某些情况下，你可能需要牺牲读取或写入性能以提高另一个性能。鉴于每个控制器都不同，这些结果可能不具有普遍性，但看起来这些结果至少大致符合这些调度器的传统智慧。我们的文章到此结束，但请密切关注下一篇文章，我们将研究不同的 Ceph 可调参数如何影响性能。在下次见到 Ceph 爱好者之前！
