Ceph Performance Part 2: Write Throughput Without SSD Journals
简介 ¶
Hello again!
如果你是第一次接触这些内容，可能需要先阅读本系列的第一篇文章，地址是 这里。
对于其他读者来说，我相信你可能已经知道 Mark Shuttleworth 和我正在进行一场激烈的战斗，看谁能为 ceph.com 网站产生更多的页面浏览量。 我做了一个完全原创且绝不不准确的图示来记录这场史诗般的战斗，供后代研究。
在撰写第一篇文章之后，我意识到我的 15 分钟互联网成名时光已经开始，我最好充分利用它，以免人们开始转回 Lolcats 和 Slashdot。 不幸的是，我用了一半的预算时间来制作上面所示的 trompe l’oeil，所以请原谅我在这篇文章中重复使用上一篇文章的格式。 事实上，你可能应该把它看作是延续，而不是一篇新的文章。 如果这让你兴奋，请继续阅读。 这次我们将研究使用上一组测试中的每个磁盘控制器，在同一设备上存储数据和日志分区的情况下，其性能如何。
硬件和软件设置 ¶
以下是我们将要测试的系统设置的回顾
The SAS/RAID Controllers we will be testing.
- High Point Rocket 2720SGL（中心顶部）： 这是一款入门级的 SAS 控制器，带有 marvel 9485 RAID 芯片组。 该型号具有仅限 JBOD 模式的固件，并且在网上仅需 150 美元即可购买。
- Areca ARC-1880（中间左侧）： 这是 Areca 之前一代的高端 RAID 控制器。 仍然被认为是相当快的。 支持磁盘的 JBOD 模式、直通模式和 RAID0-6 设置。
- Areca ARC-1222（中间右侧）： 这是一款较旧的 Areca RAID 控制器，仅包含在此比较中是因为我们碰巧有一个备用控制器。 支持磁盘的 JBOD 模式、直通模式和 RAID0-6 设置。
- LSI SAS 9207-8i（底部左侧）： 这是 LSI 最新的经济型控制器，使用 SAS2308 芯片组。 有趣的是，他们将其出厂时配置为 IT/JBOD 固件，该固件不支持任何 RAID 配置。 该卡的售价约为 240 美元。
- LSI SAS 9211-8i（底部右侧）： 哎呀，9211-8i。 它使用久负盛名的 SAS2008 芯片组，在世界各地的 ZFS 部署中被广泛使用和了解。 它基本上是一个支持 JBOD 模式和基本 RAID0/1 功能的 SAS 控制器。 似乎没有写入缓存或回写缓存。 售价约为 225 美元。
- LSI SAS 2208（未显示）： 碰巧的是，我们购买的 Supermicro 主板在其上配备了 LSI 当前的高端 SAS 2208 芯片组，具有 1GB 缓存和完整的 JBOD 和 RAID0-6 模式支持。 LSI 相应的独立卡是 SAS 9265-8i，售价约为 630 美元。
Other hardware being used in this setup includes
- Chassis: Supermicro 4U 36-drive SC847A
- Motherboard: Supermicro X9DRH-7F
- 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: 0.50
- Kernel: 3.4 from source
- Tools: blktrace, collectl, perf
作为对上一篇文章的回应，一位读者询问是否启用了硬件 crc32c 指令支持。 Ceph 本身目前未使用硬件 crc32c（它使用基于 C 的按字节切片实现），但据称 BTRFS 可以。 快速查看 /proc/crypto 显示
name : crc32c driver : crc32c-intel module : crc32c_intel priority : 200 refcnt : 2 selftest : passed type : shash blocksize : 1 digestsize : 4
理论上，BTRFS 应该在本文和上一篇文章的结果中都使用硬件 crc32c 指令。
Test Setup ¶
在本文中，重点是控制器/磁盘可以获得的原始吞吐量，因此这些测试是在使用 localhost TCP 套接字连接的 SC847a 上直接运行的。 与第一篇文章不同，控制器帮助驱动器处理对日志和数据分区进行冲突写入的能力将至关重要。 被测试的每个控制器都支持各种操作模式。 为了保持合理，我们正在测试 3 种配置，它们都使用相同数量的数据和日志磁盘
- JBOD 模式（所有控制器都支持。 充当标准的 SAS 控制器。 日志位于每个驱动器上的单独的 10G 分区上。）
- 直通/8xRAID0 模式（Areca 控制器支持，并且可以通过为每个 OSD 创建单个驱动器 RAID0 来模拟在 SAS2208 上进行模拟。 使用板载回写缓存。 日志位于每个驱动器上的单独的 10G 分区上。）
- RAID0 模式（单个 OSD 位于 8 磁盘 RAID0 阵列上。 单个 80G 日志放置在 RAID0 阵列上的单独分区上。 启用支持它的控制器的回写缓存。
根据上一篇文章中执行的测试和一些在线传言，Areca 的 JBOD 模式实际上正在使用板载缓存，并且应该与直通模式类似。 这可能会使其优于其他控制器上的 JBOD 模式。
为了生成结果，我们正在使用 Ceph 内置的基准测试命令：“RADOS bench”，它为要写入的每个数据块写入新对象。 RADOS bench 具有一定的优点和缺点。 一方面，它可以让你清楚地了解 OSD 可以以各种大小的速度写入新对象。 它不能测试的是，对现有对象进行小写入的速度有多快。 这很重要，因为这正是对 RBD 卷进行小随机写入时发生的情况。 最近，Inktank 的 Sam Just 编写了另一组基准测试，称为 smalliobench 和 smalliobenchfs，并将它们引入了 Ceph master git 分支，以模拟这些类型的 IO。 在未来的文章中，我们将开始研究这些工具，但现在我们将再次使用 RADOS bench。 同样，我们正在运行 8 个并发的基准测试实例，并汇总结果，以确保基准测试不会成为瓶颈。
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 正常工作。 我们确实将某些 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 RESULTS ¶
在我们开始之前，你可能想打开 Ceph 性能分析（一） 文章在另一个窗口中，并向下滚动到第一组测试。 我将在本文中将数字与上一篇文章中的数字进行比较。 你首先可能会注意到的是，一些控制器的性能特征与使用 SSD 作为日志时非常不同。 具有回写缓存的 RAID 控制器现在在 8-OSD 模式下处于领先地位。 看起来缓存可能有助于重新排序写入，以减轻由于日志存储在同一磁盘上而引起的额外寻道。 就像上一篇文章一样，使用单个 OSD 和大型 RAID0 阵列速度很慢。 令人惊讶的是，这不是最慢的配置。 在上一篇文章中，当使用 SSD 作为日志时，廉价的 SAS 控制器在 JBOD 模式下是测试速度最快的控制器之一（特别是 SAS2308、2720SGL 和 SAS2008）。 没有 SSD 驱动器作为日志，它们现在是速度最慢的控制器之一。 发生了什么？ 我怀疑缺乏板载缓存正在伤害它们。 写入可能需要更长的时间才能完成，我怀疑对于每个 OSD 的少量并发操作，没有足够的并发性来隐藏它。 在上一篇文章中，我们没有显示每个测试的 RADOS Bench 操作延迟，但我们收集了这些信息。 现在我们又收集了这些信息。 让我们比较结果，看看理论是否成立
点击下面的任何图片（再次点击）以放大它们…
16 并发 4K 写入操作延迟（BTRFS）
16 并发 4K 写入操作延迟（XFS）
16 并发 4K 写入操作延迟（EXT4）
确实，如果并发操作很少，拥有板载缓存的控制器或拥有 SSD 日志确实有帮助。 稍后我们将看看这种趋势是否在更多并发操作下仍然成立。 首先，让我们看看 CPU 利用率和平均磁盘队列时间。
点击下面的任何图片（再次点击）以放大它们…
16 并发 4K 写入 - CPU 利用率
16 并发 4K 写入 - 磁盘等待
如果你阅读过上一篇文章，那么在 CPU 利用率方面，应该不会有真正的惊喜。 BTRFS 继续使用比其他文件系统多得多的 CPU 资源，即使它几乎赶上了 EXT4。 至于等待时间，BTRFS 似乎在 Areca 控制器上导致极高的设备队列等待时间，尽管其性能与 SAS2208 相似。
当有 256 个并发操作时，情况会如何？
使用 256 个并发 4K 写入时，具有 BBU 缓存的 RAID 控制器仍然在 8-OSD 模式下处于领先地位，但更便宜的 SAS 控制器已经赶上了相当大的程度。 BTRFS 性能现在等于或可能甚至略快于更昂贵的控制器。 XFS 和 EXT4 性能也有所提高，但仍然落后于具有 BBU 缓存的控制器上的文件系统性能。 延迟如何？
点击下面的任何图片（再次点击）以放大它们…
256 并发 4K 写入延迟（BTRFS）
256 并发 4K 写入延迟（XFS）
256 并发 4K 写入延迟（EXT4）
在有大量并发操作的情况下，延迟在各个方面都有所增加，但速度并不相同。 更便宜的 SAS 控制器的延迟现在与高端 RAID 控制器的延迟大致相同。 你可能会注意到，在这一组测试中，如果并发操作足够多，那么在 SSD 上拥有日志或拥有 2 个额外的 OSD（尽管日志位于同一磁盘上）就没有持续的 IOP 优势。 这并不完全清楚，但它可能表明存在软件限制。 事实上，最近 Ceph master 分支的 OSD 线程和锁定代码进行了一些改进，这些改进可能会在某些情况下提高小写入的性能。
点击下面的任何图片（再次点击）以放大它们…
256 并发 4K 写入 - CPU 利用率
256 并发 4K 写入 - 磁盘等待
再次看到 BTRFS 在更高的性能配置中使用相对更多的 CPU。 在 Areca 卡上，BTRFS 的队列等待时间很高，我们也在使用 SSD 时看到了这一点。 JBOD 卡也显示 XFS 的一些较高的队列等待时间。
128KB RADOS 基准测试结果 ¶
使用少量并发 128K 写入的结果看起来与 4K 写入结果相似。 BTRFS 再次名列前茅。 具有 WB 缓存的控制器表现良好，而没有缓存的控制器表现糟糕。 Areca 卡表现特别出色； 即使是过时的 ARC-1222。 事实上，Areca 卡在此测试中，使用 8 个旋转磁盘同时提供数据和日志，比使用 6 个旋转磁盘和 2 个 SSD 的配置表现更好。 这些控制器的处理器必须做得很好，以至于日志写入对磁盘数据部分的 128k 写入影响很小。 虽然 SAS2208 是此测试中下一个最快的控制器，但它比使用 BTRFS 的 ARC-1880 和 ARC-1222 慢得多。
点击下面的任何图片（再次点击）以放大它们…
16 并发 128K 写入 - CPU 利用率
16 并发 128K 写入 - 磁盘等待
值得注意的是，此处显示的 CPU 利用率，虽然仍然很高，但与上一篇文章中相同测试的单位吞吐量相比，似乎要低得多。 这部分原因可能是因为整体吞吐量较慢。 但是，如果您将此测试的最快结果与上一篇文章中的结果进行比较，那么很明显，对于相同的性能水平，某些控制器比其他控制器具有更高的 CPU 利用率。 Areca 控制器上 BTRFS 的高队列等待时间在使用 128K 写入时消失了，而现在 XFS 似乎导致比其他文件系统更高的队列等待时间。 特别是 SAS2008 在 RAID0 模式下似乎会导致高队列等待，尽管速度较慢，这与我们之前文章中看到的现象类似。
使用 256 个并发的 128K 写入，SAS2208 的性能在 8 个单驱动 RAID0 阵列中得到了显著提升，现在名列前茅，仅略胜于 ARC-1880。 ARC-1880 在 EXT4 方面表现明显更好，而在 BTRFS 方面表现略差，在 XFS 方面表现明显更差。 无缓存 SAS 控制器的性能再次得到提升，现在与 8-OSD 模式下的 ARC-1222 性能大致相同。 在所有这些控制器上，BTRFS 的性能相对较高，而 EXT4 和 XFS 的性能较差。 在支持它的控制器上，单 OSD RAID0 模式再次相当慢。
点击下面的任何图片（再次点击）以放大它们…
256 个并发 128K 写入 - CPU 利用率
256 个并发 128K 写入 - 磁盘等待
BTRFS 的 CPU 利用率仍然很高，但对于此测试而言，不如使用 SSD 作为日志时那么高。 磁盘等待时间再次很高，这与使用 SSD 日志时的情况相同。
4MB RADOS 基准测试结果 ¶
使用 16 个并发的 4MB 写入，发生了一件非常有趣的事情。 高端 SAS2208 和 ARC-1880 控制器再次名列前茅，这并不令人惊讶。 令人惊讶的是，这些控制器上的 RAID0 配置表现良好，但仅限于 EXT4！ 事实上，使用 EXT4，SAS2208 在配置了 8 个驱动器的 RAID0 阵列时是此测试中最快的控制器。 它略胜于使用 BTRFS 配置的相同控制器。 ARC-1880 的情况也是如此，但性能在两种情况下都低约 15%。 尽管如此，我们现在开始看到将日志放在与数据相同的磁盘上时的一些限制。 尽管有 2 个额外的旋转磁盘，但此测试中最快的配置只能达到约 450MB/s，而廉价的 SAS 控制器在使用 SSD 作为日志时可以达到接近 700MB/s 的速度。 谈到 SAS 控制器，它们在没有 SSD 支持的日志的情况下仍然很慢，但至少它们看起来不像在较小的写入测试中那么糟糕。 ARC-1222 终于开始显现其年龄，尽管具有 WB 缓存，但仅勉强跟上 SAS 控制器的速度。 最后，SAS2008 在 RAID0 模式下由于缺乏缓存和较慢的处理器而无法跟上，远远落后于其他所有控制器。
点击下面的任何图片（再次点击）以放大它们…
16 个并发 4M 写入 - CPU 利用率
16 个并发 4M 写入 - 磁盘等待
在这些测试中，BTRFS 的 CPU 利用率似乎再次很高，但如果您查看比例，您会看到它仅上升到约 28%。 在之前的测试中，使用 BTRFS 时的 CPU 利用率接近 80%，但性能也高得多。 除了 Areca 卡之外，磁盘队列等待时间似乎大致相同。 ARC-1880 的队列等待时间略高，而 ARC-1222 的队列等待时间更高（尤其是在使用 XFS 时）。
随着更多的并发操作，我们再次看到 SAS 控制器得到改进，但不足以超越 SAS2208 和 ARC-1880。 当您考虑日志写入时，除了 ARC-1222 之外，所有控制器现在都能够使用 BTRFS 数据分区达到每驱动 110MB/s 以上的速度。 SAS2208 和 ARC-1880 能够推动大约 120-130MB/s，并且正在接近驱动吞吐量限制。 可悲的是，XFS 和 EXT4 的性能通常要低得多，并且经常达到每驱动 80-100MB/s 的峰值。
点击下面的任何图片（再次点击）以放大它们…
256 个并发 4M 写入 - CPU 利用率
256 个并发 4M 写入 - 磁盘等待
CPU 利用率数字和队列等待时间看起来与我们在 16 个并发 4M 写入中看到的情况相似，只是规模更大。 具体来说，在 8-OSD 模式下和使用 XFS 时，Areca 控制器上的队列等待时间要高得多。
结论 ¶
好吧，又完成了一篇文章。 现在我可以回去玩《魔兽世界》^H^H^H^H认真地处理重要问题了。（真的，已经过了工作时间！） 哦，等等，我应该在这里说些什么。 好的，首先，BTRFS 再次（至少从表面上看）看起来比 XFS 表现更好。 EXT4 的表现好坏参半，有时比 BTRFS 略好，有时几乎像 XFS 一样糟糕。 在未来，我们希望更深入地比较这些文件系统，并查看性能随时间的变化情况（提示：BTRFS 小写入性能往往会迅速下降）。 现在，如果您想要在新鲜创建的文件系统上获得最高的性能，而无需考虑 CPU 利用率，那么 BTRFS 是您的选择。
除此之外，我们看到当您将日志放在与数据相同的驱动器上时，具有写回缓存的控制器确实会产生很大的影响。 当飞行中的 IO 很少时，这一点最为明显。 即使有许多飞行中的 IO，它仍然似乎有帮助。 这与我们看到日志位于 SSD 上的情况完全相反。 在那种情况下，廉价的 SAS 控制器通常是性能最高的卡，无论有多少飞行中的 IO。
有趣的是，将日志从专用的 SSD 切换到共享的旋转磁盘似乎不会显着降低 IOP 吞吐量，但它确实会显着降低写入大型 4MB 对象时的吞吐量。 也许调整各种 Ceph 参数可以帮助解决这个问题，但也有可能 Ceph 的某些领域可以改进小 IO 吞吐量。
至于购买昂贵的控制器并使用所有驱动器托架来放置旋转磁盘，还是购买廉价的控制器并使用一部分托架来放置 SSD/日志，这其中存在权衡。 如果构建正确，具有 SSD 日志的系统可以提供更高的块写入吞吐量，而将日志放在数据磁盘上可以提供更高的存储密度。 在没有进行任何调整的情况下，这两种解决方案目前都提供相似的 IOP 吞吐量。
未来工作 ¶
我原本想写一篇关于扩展和调整的文章，但我认为在处理它之前，我们应该快速调查一下 Argonaut 与即将推出的闪亮的 Bobtail 版本。 有许多性能改进以及新的 smalliobench 基准测试工具可用，这将非常值得深入研究。 除此之外，我们仍然拥有（除了这组测试！）我们上次文章中列出的所有内容需要调查，以及我计划进行的一些其他调查。 还有很多事情要做！ 我希望这对大家有价值。 如往常一样，如果您有任何问题或建议，请随时发送电子邮件给我或在下方留下评论。
顺便说一句，如果您今年要去 SC12，请到 Ceph 展位！ 我们的展位是 #3361，就在耳语套房旁边。 我将在开幕晚宴上出现，也会在会议期间四处游荡。
感谢阅读！
