看来讲 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部署的起点。 |
