Argonaut vs Bobtail Performance Preview
目录
简介 ¶
Hello again!
战争。战争从未改变。你们中的一些人可能一直在关注我和马克·沙特尔沃斯之间的激烈竞争。现在，我完全意识到，我与他在这场灾难中的责任几乎相同。我们都做过一些无法挽回的事情，我们只需要克服它。（来吧，Slashdot？煽动性言论？你真的需要一个非常明显的点击诱饵描述吗？）无论如何，我认为是时候埋下战斧了。让 bygones be bygones，等等？我说我们都坐下来，冷静地解决我们的分歧，并在共同的……哦，我骗不了自己。解决这个问题的唯一方法是通过殊死搏斗！
哦，不是我和沙特尔沃斯。我根本没有机会。我听说 Unity 现在可以在你的梦中植入潜意识信息。我怎么能战斗，如果我甚至睡不着？不，这必须通过水生生物战斗来解决。冠军 Argonaut 能否抵御新挑战者 Bobtail 的攻击？ 90 年代初期的竞争性格斗街机游戏会卷土重来吗？ Protendo 和 Kobatashi 能够夺回他们失去的荣誉吗？战斗开始吧！
你们中的一些人可能会注意到一点差异。从技术上讲，我们实际上并没有在这里基准测试 Bobtail。你知道，在某个时候，0.55 应该就是 Bobtail。我，作为一个勤奋的小工人，进行了（并重新进行了）很多测试。然后我发现大约一天后，他们完成了测试，Bobtail 实际上将基于 0.56。好吧……你必须打破一些鸡蛋（就像我剩下的理智一样）才能做一个煎蛋。对于大多数情况，这些结果应该能很好地了解 Bobtail 将会带来什么。为什么还要摧毁我们所有的美味脑细胞来运行这些测试呢？我告诉你为什么。（就像你别无选择一样！）Bobtail 包含一整套新的增强功能，应该有助于提高小 IO 性能
- OSD 线程代码的改造
- 更细粒度的锁
- 更高效的提交（整个队列不再需要排空）
- 小写入不再显式刷新（filestore_flush_min）
要更深入地了解我们在 Bobtail 中做的一些更改，请阅读 Sam Just 的优秀文章 What’s New in the Land of OSD?
在继续之前，我应该提到当我们说我们运行了很多测试时，我的意思是很多测试。如果你的注意力持续时间和我一样短，你可能想直接跳到结论部分。图表中有些有趣的事情，但有很多数据需要吸收。谢天谢地，我没有包含在这些测试期间创建的数百张系统利用率图！
系统设置 ¶
与我们之前所做不同，这次我们只会查看一个控制器：SAS2208。没有足够的时间来测试所有控制器。SAS2208 可以很好地代表整个组，因为你可以执行 JBOD、多个单驱动 RAID0 和单 OSD RAID0 配置。
此设置中使用的硬件包括
- 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)
- 磁盘：6 或 8 个 7200RPM Seagate Constellation ES 1TB 企业 SATA
- SSD：2 个或 0 个 180GB Intel 520 SSD
- 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 的 GitBuilder 存档下载了 Ceph 0.48.2，并与 Ceph 的“next”分支进行了比较，大约在 Ceph 0.55 发布前一周左右。
测试设置 ¶
与我们之前所做类似，我们正在使用 localhost TCP 套接字连接直接在 SC847a 上运行测试。底层 OSD 代码的大部分改进都与 filestore 的工作方式有关。将网络排除在测试范围之外将有助于我们专注于这些更改带来的影响，而不会让网络延迟掩盖这些影响。
由于我们只测试一个控制器，因此我们有更多的时间来查看各种不同的测试。这次我们正在执行读写操作。我们还在测试之前文章中测试的相同控制器模式
- JBOD 模式（充当标准 SAS 控制器。不使用板载缓存。）
- 8xRAID0 模式（每个 OSD 的单个驱动 RAID0 组。使用板载回写缓存。）
- RAID0 模式（单个 OSD 在多磁盘 RAID0 组上。使用板载回写缓存。）
在 JBOD 和 8xRAID0 模式下，我们测试
- 8 个旋转磁盘，每个磁盘有数据和 10G 日志，分别位于单独的分区中。
- 6 个旋转磁盘用于数据，2 个 SSD 用于日志（每个 SSD 3 个 10G 日志分区）。
在 RAID0 模式下，我们测试
- 8 个旋转磁盘在 1 个 RAID0 中用于数据，以及 80G 的日志分区。
- 6 个旋转磁盘在 RAID0 中用于数据，2 个 SSD 在 80G RAID0 中用于日志。
为了获得结果，我们再次使用 Ceph 内置的基准测试命令：“RADOS bench”，该命令为每个要写入的数据块写入新对象。RADOS bench 具有一定的优点和缺点。一方面，它可以让你清楚地了解 OSD 在不同大小下写入和读取对象的速度有多快。它不能测试的是，从大型对象中快速读取和写入小数据块的速度有多快。
与我们之前的文章一样，我们正在运行 8 个并发的 RADOS bench 实例，并将结果汇总，以确保它不会成为瓶颈。但是，这次我们指示 RADOS bench 的每个实例写入自己的池，每个池有 2048 个 PG。这样做是为了确保在读取测试期间，RADOS bench 的每个实例读取的是唯一对象，这些对象先前未被其他实例读取到页面缓存中。你可能还会注意到，我们正在使用池每 PG 的 2 的幂次方。由于 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 文件系统运行相同的测试。在每个测试之间重新格式化文件系统并重新运行 mkcephfs，以确保先前测试的碎片不会影响结果。请记住，如果尝试使用这些结果来确定生产集群的性能，这可能会产生误导。每个文件系统似乎以不同的方式老化，并且随着时间的推移可能会表现出截然不同的性能。尽管如此，我们正在努力确保对每个文件系统进行公平的测试。将来，构建一个工具将文件系统老化到预先确定的级别并查看它如何影响结果将很有用。
我们让大多数 Ceph 可调参数保持默认状态进行这些测试，除了：“filestore xattr use omap = true”以确保 EXT4 正常工作。在 0.55 中，CephX 身份验证默认启用，而之前它已被禁用。我们在 0.55 中显式禁用它，以匹配 Argonaut 中的默认行为。我们向底层文件系统传递了某些 mkfs 和挂载选项，在有意义的情况下
- 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 mount options: -o noatime
- mkfs.ext4 options: (-b 4096 -E stride=16,stripe-width=128 for RAID0 tests)
- ext4 mount options: -o noatime,user_xattr
During the tests, collectl was used to record various system performance statistics, and perf was used to gather profiling data on the running processes. blktrace was also run against every OSD data disk so that we could potentially go back and examine seek behavior on the underlying block devices.
4KB RADOS BENCH 写入结果 ¶
好吧，一开始一切看起来都很好。使用 8 个旋转磁盘和少量并发 4K 写入，BTRFS 和 XFS 显示出不错的改进。有趣的是，只有在使用了 8 个单磁盘 RAID0 阵列时，EXT4 才会显示出轻微的改进。否则，它显示出明显的退化。让我们看看增加并发 IO 数量会发生什么。
casino online src=”https://ceph.net.cn/wp-content/uploads/2013/12/AVB_256Concurrent4KWrite8Disk.png” alt=”" width=”576″ height=”432″ />Bobtail 再次提供了 XFS 的显著改进，并为 BTRFS 提供了一些小的改进。EXT4 性能在 8xRAID0 配置中有所改善，但再次在 JBOD 和单 OSD RAID0 测试中退化。
我想指出的一点是，BTRFS 的数字对于 Argonaut 和 Bobtail 都有所改善，相对于我们之前所做的测试。可能有两个差异可以解释这一点。一个是，我们现在将每个文件写入自己的池，而不是写入单个池。也许在单个池测试中，数据没有得到理想的分布，或者某些瓶颈限制了小 IO 吞吐量。另一个差异是，以前文章中的测试使用内核 3.4 运行，而这些测试使用 3.6.3 运行。完全有可能新内核包含增强功能（尤其是针对 BTRFS！），从而提高了性能。
一些奇怪的结果！例如，为什么在 8xRAID0 配置中使用旋转磁盘时，写入速度比将日志放在 SSD 上更快？是的，我们放弃了两个 OSD，但磁盘上的负载减少应该足以弥补这一点。另一方面，BTRFS 性能在 JBOD 模式下使用 SSD 日志比使用旋转磁盘更快。谜团需要探索！（但现在不行！）BTRFS 性能在 JBOD 的情况下得到了 Bobtail 的改进。XFS 性能似乎在 JBOD 和 RAID0 的情况下也有所提高，并且可能在 8xRAID0 的情况下略有提高。可能太接近了，无法判断。EXT4 性能在 JBOD 和 8xRAID0 的情况下没有太大变化，但似乎在 Bobtail 的 RAID0 配置中再次退化。
啊哈，现在看起来更接近我们预期的结果了。 8xRAID0模式再次领先，尤其是在Bobtail上。 Bobtail在8xRAID0和JBOD模式下都显示出BTRFS性能的显著提升。 XFS性能全面提升。 EXT4性能好坏参半，JBOD和单OSD RAID0模式显示出性能下降，而8xRAID0性能有所提升。
4KB RADOS 基准测试读取结果 ¶
所以这是我们第一次进行读取测试，哇：EXT4和XFS性能在JBOD和8xRAID0模式下得到了显著提升！ 在某些情况下，读取速度比Argonaut快3倍！ BTRFS性能没有太大变化，单OSD RAID0模式也没有太大变化。 尽管如此，看起来核心团队在提高小IO性能方面所做的工作确实产生了效果。
再次，一些非常有趣的结果。 BTRFS性能基本保持不变。 XFS在JBOD模式下有了显著的提升，但8xRAID0测试中似乎发生了一些奇怪的事情。 性能下降了，并且在256个并发线程的情况下，性能实际上低于我们之前看到的16个线程的结果。 真正的明星是EXT4。 在Argonaut中，EXT4性能优于XFS，但仍然比BTRFS差很多。 在Bobtail中，EXT4在JBOD和8xRAID0模式下都击败了BTRFS。
在我们开始之前，我想指出一点，SSD日志并不能提高读取性能。 事实上，通过使用一些可用的插槽用于SSD驱动器，我们正在减少可以测试的OSD数量。因此，实际上我们在这里测试的是6个OSD上旋转磁盘的读取性能，而不是之前有8个OSD的测试。 因此，故事并没有太大变化。XFS和EXT4在JBOD和8xRAID0模式下都有显著提升。 在这种情况下，BTRFS在JBOD模式下也看到了一点提升。
再次，故事与8个旋转磁盘的情况非常相似。 请注意，XFS性能再次在Bobtail的8xRAID0模式下下降，因此8个磁盘的结果似乎不是异常值。 EXT4性能再次显示出Bobtail的显著提升，但这次不足以击败BTRFS。 这似乎表明，至少在Bobtail中，EXT4可能比BTRFS随着每个节点的驱动器数量增加而更好地扩展。 鉴于BTRFS过去在文件系统碎片和性能下降方面存在一些问题，这可能使EXT4成为专注于小读取的应用程序的理想选择。
奖励：来自页面缓存的4KB RADOS基准测试读取结果 ¶
我第一次运行所有这些测试时，忘记确保我的脚本在写入和读取测试之间清除缓存。 这意味着所有4KB读取都直接来自页面缓存。 与其丢弃这些结果，我想我的时间损失应该成为你的收获。 我在这里包含它们是为了展示Ceph在直接从内存读取时的表现（请注意，这些测试使用默认调整参数，因此通过调整可以改善结果）。
由于我们正在从页面缓存读取，所有文件系统都表现得相当相似。 在JBOD和8xRAID0情况下，Bobtail比Argonaut提供了不错的15-20%的性能提升。 它似乎也可能略微提升RAID0性能。 这里有趣的是，似乎存在大约4000 IOPS/OSD的限制。 让我们看看增加并发操作的数量是否有帮助。
在单OSD RAID0情况下，我们再次受到4000 IOPS的限制。 投入更多的并发操作并没有改善情况。 在其他两种有8个OSD的情况下，性能得到了显著提升。 在这些情况下，Bobtail提供了大约20%的提升。 使用8个OSD，每个OSD似乎能够达到大约3000 IOPS，或者大约24,000 IOPS的总和。 请记住，客户端正在运行在localhost上。 但是，它们正在使用所有标准的Ceph messenger代码和标准的TCPIP堆栈。
使用较少的并发操作，6个OSD的性能看起来几乎与8个OSD相同。 根本没有足够的并发操作来使OSD保持繁忙。 单OSD RAID0结果看起来大致相同，因为有足够的并发操作来饱和单个OSD。
Bobtail再次显示出在这些测试中优于Argonaut的不错改进。 这里有趣的是，使用6个OSD，我们看到的结果与使用8个OSD的结果非常接近。 在这种情况下，每个OSD都在执行大约3.8K IOPS，非常接近我们之前看到的4K IOP限制。 总体性能在这种情况下约为22.5K IOPS。 这似乎意味着，无论OSD的数量如何，我们可能正在接近Ceph在此服务器上大约24-25K IOPS的瓶颈。
128KB RADOS 基准测试写入结果 ¶
使用128K写入，情况看起来比4KB时要模糊得多。 XFS性能全面提升，这很好。 BTRFS性能没有太大变化。 EXT4性能是我们需要关注的问题。 在JBOD模式下，我们看到适度的提升，而在8xRAID0模式下，我们看到适度的下降。 最大的变化是RAID0性能。 我们已经看到单OSD RAID0模式往往很慢。 在这种情况下，EXT4性能非常慢。 Bobtail甚至不如Argonaut快一半，并且在任何其他配置中都表现得更慢。
使用更多的并发操作，情况并没有太大变化。 XFS性能再次在Bobtail中得到显著提升。 尽管有所改进，但它仍然落后于所有配置中的EXT4和BTRFS。 BTRFS性能在8xRAID0模式下显示出不错的提升，但除此之外没有变化。 Ext4性能再次好坏参半。 在JBOD模式下，Bobtail正在提高性能，但在8xRAID0模式下，性能有所下降。 在单OSD RAID0模式下，Bobtail显著下降。
好吧，让我们先说出显而易见的事情。 无论什么原因，BTRFS在JBOD模式下的表现比任何其他组合都好得多。 Bobtail只是让它又快了30%。 否则，使用6个OSD和2个SSD作为日志的性能通常与使用8个旋转磁盘相当或更低。 鉴于将日志写入移动到SSD应该允许旋转磁盘做更多的工作，这令人失望。
好的，说完这些，有趣的消息是Bobtail在JBOD模式下显著提高了BTRFS性能，但对其他RAID模式没有太大影响。 XFS性能有所提高，而EXT4性能在JBOD和8xRAID0模式下有所提高，但在RAID0模式下再次下降。
好吧，使用256个并发操作，BTRFS继续碾压其他文件系统，Bobtail只是让这种差异更加明显。 Bobtail大大提高了JBOD和8xRAID0模式下的EXT4性能。 在RAID0模式下，性能再次下降。 XFS性能全面提升，但相对于EXT4和BTRFS来说太慢了，所以没有太多值得兴奋的地方。
128KB RADOS 基准测试读取结果 ¶
使用128K读取，整体性能看起来比写入略好。 Bobtail与Argonaut的对比情况看起来有些混乱。 单OSD RAID0性能在所有文件系统中都随着Bobtail而下降。 JBOD性能在BTRFS和XFS上略有提升，但EXT4可能太接近了，无法判断。 在8xRAID0模式下，Bobtail提高了BTRFS性能，略微降低了XFS性能，并大大降低了EXT4性能。
唉。 8xRAID0性能在Bobtail下全面下降。 BTRFS和EXT4性能在JBOD模式下都有所下降。 Bobtail明显更快地测试是BTRFS RAID0测试。 不幸的是，这个结果不是很感兴趣，因为它比其他配置慢得多。 总体而言，这些结果令人失望，因为我们希望看到与4KB读取测试中相似的改进。
使用6个OSD和16个并发操作的结果并不令人放心。 有时Bobtail会略胜一筹，但总体结果与Argonaut相当或更慢。 单OSD RAID0结果尤其显示出性能下降。
好消息是，使用256个并发操作在6个OSD上，Bobtail显示出比8个OSD测试更少的性能下降。 坏消息是，性能更高的配置，如BTRFS在JBOD和8xRAID0模式下，显示出轻微的性能下降。 我认为更大的图景是，Bobtail和Argonaut的128K读取数字都低于我们希望的水平。 这是一些我们将来肯定会进一步研究的事情。
4MB RADOS 基准测试写入结果 ¶
使用16个并发4MB写入，Bobtail和Argonaut之间的差距看起来很小。 BTRFS结果在Bobtail和Argonaut之间大致相同。 XFS性能全面提升，而EXT4性能再次在8xRAID0和单OSD RAID0配置中下降。
使用更多的并发操作，情况明显好转。 BTRFS性能在8xRAID0测试中有所提高。 EXT4性能在所有配置中都有所提高，并且XFS性能似乎也有所提高。
如我们在上一篇文章中所示，SSD日志在执行JBOD控制器上的大型顺序写入时真正闪耀。 在这里，Bobtail和Argonaut之间的所有内容看起来都非常相似，除了在JBOD配置中XFS性能的适度提升。
使用更多的并发操作，缓存不再成为障碍，实际上有助于提高8xRAID0模式下的BTRFS性能。 话虽如此，Bobtail实际上似乎比Argonaut在该测试中慢一点，但结果相差不大。 在8xRAID0模式下，XFS和EXT4性能都有所提高。 否则，Bobtail和Argonaut表现得非常相似。
4MB RADOS 基准测试读取结果 ¶
4MB读取使性能看起来更好。 Bobtail与Argonaut的对比情况看起来有些混乱。 单OSD RAID0性能在Bobtail下有所下降。 JBOD性能在BTRFS和XFS上略有提升，但EXT4可能太接近了，无法判断。 在8xRAID0模式下，Bobtail提高了BTRFS性能，略微降低了XFS性能，并大大降低了EXT4性能。
使用更多的并发操作，数字看起来更好（至少在8xRAID0和JBOD模式下）。 看起来BTRFS性能在Bobtail下略有下降。 EXT4性能在所有配置中都有所提高。 看起来XFS性能在两个版本之间没有太大变化。
这里没什么好说的。结果类似于在 8 个 OSD 上进行的 16 个并发请求测试，只是因为现在我们有 6 个 OSD 用于读取，而不是 8 个，所以速度较慢。
好的，在我们的最后一组测试中，我们再次看到 BTRFS 在高端性能上略有下降，而在低端性能上略有提升。除此之外，Bobtail 和 Argonaut 的所有结果都相当可比。
结论 ¶
天啊，终于结束了吗？我自由了！自由了！！！呃，好吧，还没完全结束。所以，在盯着所有这些图表几个小时之后，我们学到了什么？让我们快速回顾一下，看看性能在所有这些测试中是如何变化的。再次说明，我们只有时间运行每个测试的单个实例，所以这些结果中可能存在一些噪声。将来，运行每个测试的多次迭代来检查这一点会很好。话虽如此，让我们看看我们得到的结果。
在这种形式下，很容易看出 4K 读取和写入性能得到了多少改进，唯一的例外是 EXT4 写入。我们需要回去研究为什么会这样，但我们目前的想法是，禁用 EXT4 上的小写显式刷新可能没有好处。如果您运行 XFS 或 BTRFS，升级到 Bobtail 应该可以提供显著的小 IO 性能提升。对于 EXT4，您的写入吞吐量可能会下降，但看起来读取吞吐量应该会显著提高。
对于 128K IO，Bobtail 显著提高了 XFS 的写入吞吐量，但我们再次看到一些 EXT4 性能下降的情况。BTRFS 写入性能在一些情况下有所提高，没有出现重大下降。在读取方面，情况并不乐观。在许多情况下，性能有所下降。虽然也有一些胜利，但我们希望看到更多的收益，考虑到已经进行的性能改进。我们将不得不回去弄清楚是什么在阻碍我们。
最后，对于 4MB 传输，性能差异更加微妙。Bobtail 为提高小 IO 性能而进行的大多数更改对大 IO 性能的影响较小，因此这并不完全出乎意料。话虽如此，我们确实看到 XFS 写入性能有显著提高。除此之外，还有一些胜利和失败（尤其是在 EXT4 性能方面有一些大幅波动），但总的来说，Bobtail 和 Argonaut 的性能相当相似。
好了，这就是全部。在 Ceph 性能测试中又度过了一天。下次我们将研究 smalliobench，然后研究各种 Ceph 可配置参数的参数扫描，以了解它们如何在不同情况下影响性能。Ceph 爱好者们，下次再见！
