介绍

Ceph是一个 Linux PB 级分布式文件系统。一个让ceph强大的原因就是ceph提供了一系列的可调整的选项。你可以控制ceph管道中的多少数据以及多少操作被缓存。你可以定制不同的清除策略， 或者更改文件存储操作的线程数。不利的一面是，要深入研究可能有点吓人，甚至让人不知道如何下手。在Inktank我们得到了很多关于这些选项如何影响性 能的问题。答案往往是视情况而定。不同的硬件和软件配置将有利于不同Ceph选项。为了让人们知道什么东西可能值得看,我们决定过一遍一些最有可能会对性 能产生影响的选项。本文中,使用磁盘JBOD配置时，我们将看到不同的ceph参数。

因为Inktank是愿意支付我画网络漫画(嗨伙计们!)，我看到的一切就相当于下面这幅画。

在我们继续之前，如果你不是很很熟悉ceph的配置，这是关于ceph的配置文档。 一旦你对此有所了解，你要查看的可调参数在这里： here。 

系统设置

我们将使用SAS2208 控制器进行这个测试。这支持JBOD，多重RAID0，单RAID0配置。不幸的是不同的控制器上的表现也不同,所以这些结果可能并不代表其他控制器。希望他们至少会提供一个初始的起点,或许想类似的配置如何执行。

硬件配置包括:

• Chassis: Supermicro 4U 36-drive SC847A

• Motherboard: Supermicro X9DRH-7F

• Disk Controller: On-board 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

软件配置：

• OS: Ubuntu 12.04

• Kernel: 3.6.3 from Ceph’s GitBuilder archive

• Tools: blktrace, collectl, perf

• Ceph: Ceph “next” branch from just before the 0.56 bobtail release.

测试设置

写了一个python工具来读取YAML配置文件，以及根据不同的参数设置自动生成ceph.conf配置文件。然后我们使用基准测试工具对每个配置文件进行测试。一些参数配置将被组合在一起以减少总的测试数量。以下YAML文件片段展示了不同的设置。

类似于以前的文章,我们运行测试直接在SC847a使用本机t TCP套接字连接。我们在每块磁盘的起始部分设置10G的日志分区。本文章只对 SAS2208的JBOD模式进行测试，这种模式不使用主板缓存。其他模式可能在后面的文章进行测试。CFQ用作所有测试IO调度器。

我们使用的是Ceph的可靠的内置基准测试命令:“RADOS bench” 来生成结果。（我今后将写一篇用smalliobench来测试的文章）。rados bench 有一定的好处有缺点。一方面它将明确地显示不同大小的对象读写速度。但它并不显示小IO大对象执行的速度有多快。出于这个原因,这些结果并不一定反映 RBD如何最终执行。

类似之前的文章，我们将执行8个并发的 RADOS bench来合并结果，以确保这不是一个瓶颈。我们让每个RADOS bench 实例分别往自己的pool写2048个pg。这样做是为了确保后面的测试实例读取到独一无二的对象，而不是之前读取的对象的缓存。您可能还注意到,我们使 用的每个池的PG数量是2的整数幂个。由于Ceph的方式实现PG分裂行为,有一个2的整数幂的后卫(尤其是在低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集群是如何执行将是一个误导。每个文件系统在不同的阶段可能运行的机制完全不同。尽管如此,每个测试重新格式化文件系统是必要的,以确保不 同的测试之间比较公平。每个文件系统的格式化命令和挂载选项如下:

• mkfs.btfs options: -l 16k -n 16k

• btrfs mount options: -o noatime

• mkfs.xfs options: -f -i size=2048

• xfs mount options: -o inode64,noatime

• mkfs.ext4 options:

• ext4 mount options: -o noatime,user_xattr

在测试期间,collectl用于记录各种系统的性能统计数据。

4KB RADOS BENCH 写入测试结果

好吧,希望这个图表展示是不言而喻的,但如果不是,基本上这里的想法是,我们有3个样品为每个文件系统,大量的不同的参数,我们画一个彩色圈表示性能高于 或低于默认配置。可能这里最需要注意的是当 filestore flusher 显示启用的时候，BTRFS和XFS的性能变低。除此之外，看起来是授权 journal_aio_true 性能提升最为明显。

就像16个并发操作的结果一样，当启用filestore flusher 的时候BTRFS和XFS性能变低。授权 Journal AIO依然性能提升最为明显。在256个并发操作的情况下，我们可以看到，增加并发操作可以提升性能，减少并发数统一会降低性能。

4KB RADOS BENCH 读取测试结果

在这里启用 flusher 的性能依然表现不佳，这明显地降低了XFS和EXT4文件系统的读取性能。禁用调试看起来和增加并发线程操作数一样对提升性能有帮助。

这一点上，我们非常确定，启用flusher对小IO读取性能一点帮助都没有。禁用调试看起来依然有积极作用，这可能对大量的小IO操作生产的大量 消息日志处理很有帮助。有趣的是增加并发操作数似乎降低了EXT4文件系统的性能，否则我们就可以得出一个规律，越多的并发操作数，性能越高。还要注意有 多少不同的参数似乎在这些结果增加XFS的性能。我有一种感觉，默认的配置对XFS文件系统来说，性能是最好配置性能和最差配置性能的平均水平。

128KB RADOS BENCH 写入测试结果

默认情况下,filestore flusher只是支持操作大于64 k。通过显式禁用它,我们看到BTRFS不错的性能提升,但对XFS相反的效果。授权Journal AIO再次提升了性能。

在这种情况下禁用flusher给EXT4的性能提升。更有趣的是，多所有的IO大小操作都显示地禁用flusher会降低性能，尽管我们在做128k的操作。journal AIO再次提高性能,有少数增加或减少性能的其他选项。

128KB RADOS BENCH 读取测试结果

又有一些不同的选项,可以提供一些性能改进(看似BTRFS),但最明显的影响读取性能似乎是OSD 操作线程的数量就像在4 k阅读测试中的一样。

我们再次看到“默认”配置的情况下,性能很低。在这种情况下,也许有点偏高(即很多其他事物看起来低)。已经说过,OSD OP线程的数量又似乎有一个非常明显的效果。

4MB RADOS BENCH 写人测试结果

看了禁用flusher和授权 journal AIO 再次提升了写人性能。

跟之前的写入测试结果相比，这次结果很怪异!禁用flusher并不能提升性能,启用它也不能提升性能。启用Journal AIO降低了BTRFS的性能。限制缓存和队列中允许的数据大小也降低了性能。对BTRFS来说，提高这个数量去降低了性能。不知道如果我们每个测试有 100个样本会不会更好一些。

4MB RADOS BENCH 读取测试结果

啊哈!更意想不到的结果！看起来OSD 操作线程数量仍然产生了影响,但对于XFS和EXT4性能是随着线程的数量增加而降低。看起来像禁用消息中的CRC32C也可以提升性能。

最后有并发读取操作,我们再次看到,OSD OP线程数量的增加伤害EXT4和XFS的性能。对于BTRFS,看起来与4个 OSD 操作线程数达到高性能峰值。

测试结果概要

上面所示的散点图给我们一个不同的参数对于不同的输入输出大小如何影响性能相的印象，但没有给出具体每个参数是如何影响性能的答案。让我们分别看看 每个参数。接下来的图表中，每个参数的测试样本的平均值和标准差是根据默认配置的平均值和标准差计算和对比得出的，仅显示评价值之间的百分比差异。如果结 果的标准偏差范围重叠,不做颜色。如果标准偏差范围不重叠和参数平均值较高,结果是在绿色的颜色。如果范围不重叠和参数平均水平较低,颜色红。

这看起来EXT4通过增加允许不同的队列和缓冲区的字节数定义在我们的“大字节”测试中性能可以得到提升。已经说过,似乎大量并发操作时,始终只对EXT4性能提升有效。

在大量小IO操作的情况下，增加队列允许的操作数是明显有效提升性能的。有一个相当明显的例外是对于EXT4的读取。通过单独地测试每个组，我们可以隔离其他的影响因素，保持测试的有效性。

禁用调试似乎和小IO操作性能有好处,尤其是对读取性能。这有可能是OSD操作并发数的影响，所以值得试试更少的操作并发数的情况，看看结果怎么样。

有趣的是，将文件存储操作线程数从默认的2变为1时，对中小数据的操作性能提升有积极作用。这有可能是因为我们在每个osd的磁盘使用了JBOD配置。

增加filestore op线程的数量从2到4可能提供了一个轻微的改善,但整体表现似乎是大致相同的。

filestore op线程的数量从2增加到8然而似乎会导致一些性能回归

看来讲 XATTRS 放在文件系统中还不如将它放在底层数据库更能提升性能。对于XFS来说这也许有点快，但这些结果可能不够精确地说明。

默认情况下，filestore flusher 是被启用的，但仅允许64kb或者更大的数据操作才生效。当我们显示地关闭flusher的时候，居然对EXT4文件系统下256线程的4k数据写操作影 响那么大，这是很奇怪的，我怀疑这是EXT4文件系统测试结果的误差。在较大的输入输出大小,结果好坏参半。看来着对BTRFS是比较有意义的，起码完全 脱离了flusher的影响。

显式地启用flusher几乎普遍性不利于小操作,除了4 k数据对 EXT4文件系统写入。如果你有读过我们的文章：Argonaut vs Bobtail Performance Preview ，我们注意到小EXT4读取性能有所改善,而EXT4写性能退化。Argonaut版本默认对所有的写操作开启flusher，而Bobtail版本改为对64k及以上的操作才开启。看来如果你使用EXT4，你当前只能选择快速地读写小文件。

journal AIO似乎能提升所有的写入操作性能,除了大量的并发大IOs。我们将考虑在ceph的后续版本作为默认选项。

8 个 osd的主机和12个2.0 ghz Xeon E5核心,禁用CRC32c计算在信使不削一顾。我们不可能绑定CPU。在两种情况下,它似乎有所不同,我要担风险,说我们没有足够的样品。

这里的结果似乎相当没有说服力。我想我们又需要更多的样品。

再次,结果似乎相当没有说服力,虽然也许希望。OSD磁盘线程的数量增加到4可能有正面的影响。

8个OSD磁盘线程,看起来可能会有一些负面影响,除了一个积极的。我们可能需要更多的样本。

减少OSD op线程的数量从默认的2 到1是普遍不利于性能除了几个特定的场景。如果使用EXT4和做很多大读取操作，看起来像它可能提供一个温和的性能提升。

我们之前有说过这个，但反思一下，将osd 操作线程数从2提高到4，似乎是错的。提高osd操作线程数性能显著提升，除了EXT4和XFS下的大数据读取是性能降低的。

进一步增加osd 操作线程数，结果有好有坏。

鉴于我们通常是可疑的关于256个并发4 k XFS读取的结果,减少队列中允许的字节数的性能不好,尤其是大的IOs。令人惊讶的是,减少这些值不会导致更大的降低性能。

最后,减少队列操作数肯定会导致性能下降。当256线程读取的时候我们又看到了一个疑似异常。对于大的IO看来是某个地方存在瓶颈。

结论

虽然在这个实验我们看起来得到了一些结果，但是我想重申，每个测试我们只有三个样本，这样对于辨认细微的性能差异是不具有说服力的，还可能存在一些偏差。除此之外,很可能不同的硬件和软件配置将显示不同的结果。所以要以适当的粗粒度来看待这些结果。

可以说从这个实验我们学习到了ceph的一下特性。也就是说flusher不值得使用（当然有一些例外），jouranl AIO 是值得使用的，OSD操作数也有积极的作用。也许还有许多其他的地方我们需要隔离性能。这将是有趣的测试修改filestore同步间隔,并改变子目录合 并和分裂行为。我希望这篇文章是有用的,它可以为人们提供一个调整自己的Ceph部署的起点。