原文链接

知乎专栏: [译]Ceph性能优化之CPU核数对性能的影响 - Part 1 - 知乎

简介

Ceph在很多方面都做得很好，但从来没有人意识到它有极低的资源消耗。Ceph需要做一些工作来确保数据的一致性，以及如何将数据(PG)放到合适的位置。我们正在努力优化Ceph的IO路径，但事实是，Ceph在一直以来需要相当多的CPU来实现高速存储设备(如NVMe驱动器)的高性能。今年夏天早些时候，一位用户找到我们的团队，对低CPU核心数下的性能表示担忧。他们得到了一个建议，当使用NVMe驱动器时，每个OSD应该分配2个核。该建议没有解释原因。他们决定购买硬件，尽管只有一半的NVMe驱动器槽被填充(即每个OSD有4个内核可用)。在这种配置中，性能是可以接受的，但是用户担心当他们用NVMe驱动器完全填充满服务器时可能会发生什么。遗憾的是，我不得不告诉他们，通过增加更多的驱动器，他们可能只会看到容量的增加，而不会看到性能的提高。最初的建议并非完全没有价值。如果用户不关心小的随机IO的性能，每个OSD 2核可能是一个很好的价值主张。在NVMe驱动器上运行Ceph有很多好处，除了提高小的随机IO性能。然而，对于这个用户来说，小的随机IO是一个问题，这正是CPU资源最重要的情况。

遗憾的是，这不是第一次出现这个问题，关于这个话题有很多困惑。2年前，我们更新了上游Ceph文档，PR文档中提供更好的指导。当时，我们的粗略指导是(在复制之前!)

core per 200-500 MB/s
core per 1000-3000 IOPS

这里最重要的方面是IOPS性能。本文将关注Ceph小随机IOPS性能如何随着CPU资源的增加而扩展。

集群设置

所有节点都位于同一台Juniper QFX5200交换机上，并通过一条100GbE QSFP28链路连接。构建集群并使用CBT执行fio测试。除非另有说明，每个节点都配置为最多承载6个osd，并使用librbd引擎配置4个fio进程。Intel系统上一个重要的操作系统级优化是将调优配置文件设置为“延迟-性能”或“网络-延迟”。这主要有助于避免与CPU C/P状态转换相关的延迟峰值。基于AMD Rome的系统在这方面似乎没有那么敏感，但是调优配置文件仍然设置为“网络延迟”，用于这些测试。

测试布局

CBT被配置为部署Ceph时使用了一些修改过的设置。首先，禁用rbd缓存，每个OSD分配8GB的内存目标，使用msgr V1，禁用cepx。在最近的测试中，我们看到带有默认cephx身份验证的Msgr V2的性能似乎类似，尽管在服务器和客户端上启用过线加密时，在CPU使用率类似或更高的情况下，可能会导致高达30-40%的性能损失。Fio被配置为首先用大的写预填充RBD卷，然后是3次4K随机读，然后是iodepth=128的4K随机写，每次5分钟。CBT允许用其他程序或环境变量包装osd，使用numactl控制osd可以在系统上使用多少个内核。初始测试是在单个OSD和1X复制的情况下执行的。在多个osd和3次替换的情况下进行多osd测试。

单个OSD测试

在多osd集群上，ceph以伪随机的方式确定地放置数据。在给定的时间点很可能有热点。一些osd会比其他的做更多的工作，从而导致总体性能下降。最终，整个集群的性能受制于集群中最慢的OSD的性能。针对单个OSD进行测试可以消除这种行为，并进一步消除额外的复制延迟和开销，确保OSD以最高效率工作。测试单个OSD并不代表真正的集群能做什么，但它确实显示了给定的OSD在最佳条件下的表现。

这里要注意的第一件事是，2到4核之间的性能提高了大约100%。这几乎是一个线性的改进。但在4核之后，增益开始放缓。从4核到16核只能产生另一个100%的增益，在10核时几乎完全持平。写性能的比例更高，在14-16个分配的核上最高可达350%左右。但Ceph OSD真的在这些测试中使用了所有这些核吗?

事实证明，为osd分配更多的内核可以持续地提高性能，最多可达到14-16个内核，但在高内核数的情况下，osd不会持续地使用它们所给定的所有核。对于读尤其如此。更多的核意味着更高的性能，但效率下降越高。然而，所使用的每核IOPS却保持相对平稳。为什么会这样，限制是什么?默认情况下，Ceph OSD每个OSD有80多个线程，但从资源消耗的角度来看，最重要的是:

16 OSD worker threads (8 shards with 2 threads each)
3 async messenger threads
1 bluestore key/value thread
1 bluestore "finisher" thread
RocksDB flush (high priority) and compaction (low priority) background threads

在这里不深入讨论细节(我们将在后面的博客文章中讨论)，一个OSD实际最多可能使用23个核左右。在5分钟的时间内，存量线程计数在实验室中达到的最高使用率是大约18-19核，用于4K随机写入，没有对OSD施加限制，并且禁用了RocksDB的预写日志。为什么我们在这些测试中看不到呢?可能的答案是ceph不能让所有16个工作线程一直忙着。在IE中，工作线程在做更多的工作之前会等待很短的时间。虽然一个OSD平均可能使用6或8个核心，但当它可以在短时间内爆发16个以上核心时，它可能表现最好，而其他时候它可能只需要3-4个核心。在这种情况下，如果施加核的限制，在裸金属上运行Ceph可能比在容器或vm中运行Ceph更有优势。

60 OSD集群测试

在单个OSD测试中观察到的趋势是否也会在整个集群部署时发生?

在查看60个OSD集群测试结果时，一些现象便马上突出出来了。虽然曲线与单个OSD的测试相似，但对于读操作，每个OSD的性能达到巅峰时使用的核数约为8-10，对于写操作，每个OSD的性能达到巅峰时使用的核数约为12个。在单个OSD测试中，读和写收益分别达到了大约200%和350%。在完整的集群配置中，收益最高分别为100%和250%。

通过只是简单看看osd.0，看起来更大的集群中的osd在随机读测试中使用的核更少。同时，分配的每核IOPS和使用的每核IOPS数值也都要低得多。在写端，现在使用的是3副本。为了能够与单个OSD测试进行比较，我们必须看考虑了复制因素的OSD的iops。即使这样做，每核写性能也比单个OSD测试低很多。好消息是，文档中的估计似乎相当有效。在读端，Ceph提供的IOPS大约是7500 /核，根据分配给osd的核数，每个核分配的IOPS在2400到8500之间。在写方面，Ceph每使用一个核提供大约3500个IOPS，每分配一个核提供1600到3900个IOPS。这些数字比我们两年前宣称的要好一些，我们在最近的Quincy发布中做了进一步的改进。

单osd vs 多osd NVMe性能

另一个经常出现的问题是Ceph如何很好地利用NVMe磁盘。通常这是把对本地硬盘的读取数据作为基准测试，用户想知道为什么Ceph在有更多驱动器支持的情况下还是比较慢。简单地说，Ceph确实比直接写入磁盘要慢，原因有很多。最重要的一些:

为计算crush放置、crc校验、加密、ec、网络开销等引入的时延
处理数据(编码/解码/等等)，以及在线程或者RocksDB之间分配/复制/移动内存中的数据
Ceph不仅会写数据，还会写对应的元数据。这在小写时影响尤其明显。
允许线程在没有工作时休眠，并在工作到来时唤醒它们。这样做是为了减少静默期的CPU开销，但是当线程在睡眠状态以及唤醒状态之间切换很快时，这可能会对性能产生重大影响。稍后的一篇博文将对此进行更详细的讨论。

如果没有大量的工作，其中一些是很难改善的。Ceph总是在一定程度上受到通过网络进行通信和处理网络堆栈的限制(尽管像dpdk这样的东西可以有所帮助)。为了计算PG的位置，Crush总是会引入一些延迟，而且总是会有crc32、编码/解码等引起的某种级别的额外延迟。话虽如此，单个OSD测试和多OSD测试之间仍存在很大的性能差异。

这些图表有点粗糙。尽管60个OSD的集群提供了大约200万的随机读IOPS，但是一个单独的OSD能够在更好的效率下提供近4倍于每个nvme /osd的性能。在写方面，事情稍微接近，但单个OSD的速度仍然是每个nvme/osd的大约2倍。然而，并不是一切都失去了。在Ceph的 Quincy版本中，我们努力改进写路径的性能。通过Ceph Quincy版本的改进和RocksDB的配置调优，我们可以在60个OSD的集群上实现了超过40%的4K随机写IOPS提升。

要了解我们是如何得到这些结果的，请参阅 RocksDB Tuning Deep Dive

结论

最终，在集群级别和OSD内部仍然有很大的空间来实现更高的性能。在未来的博客文章中，我将深入研究在低和高核心计数时限制性能的一些问题，以及如何进一步改进Ceph的想法。在此之前，在选择分配给由NVMe驱动器支持的osd的核数时，需要进行权衡。每个OSD有2-4个核，Ceph可以在小的读写过程中使用所有的核。增加额外的核(甚至每个osd最多16个以上)可以提高性能，但是随着核数的增加，每核的收益会变少,每个核的使用效率保持相对稳定，但是当分配更高的核数时，osd在充分利用所有可用核方面变得不那么一致。这不仅会影响前期的采购决策，还会影响有关电源和冷却等基础设施的决策，甚至影响有关容器/VM资源利用限制的决策。

最后，这篇文章关注的是Ceph Pacific版本，但从那时起Ceph的效率和性能都有所提高。跟Quincy版本相比，这些曲线看起来可能会有点不同，而几乎可以肯定的是，在Reef版本的情况也会有所不同。这些测试也在新集群上运行，在已经大量老化集群上可能看起来也会不一样。然而，我希望这篇文章至少提供了一个起点，说明在使用nvme时，CPU资源如何影响Ceph的性能。感谢阅读!