介绍通常情况下，Ceph的整体性能还是不错的，大量的场景优化为Ceph集群提供了可靠的性能保障。但是很少有人知道，Ceph目前并没有充分发挥硬件的性能，也就是说集群的性能和硬件的性能并不是线性增长的。目前，我们正在研究各种方法来优化Ceph的数据路径，但现实是Ceph一直需要相当大的CPU来充分利用NVMe等高速存储设备。前一段时间，一位用户向我们提出了对低CPU核心性能的担忧。我们的建议是在使用NVMe磁盘时为每个OSD分配2个CPU内核。我们没有试图解释原因。最终用户购买了相应的硬件服务器，服务器只插入了一半的NVMe盘（即每个OSD有4个CPUCores可用）。一般情况下，这种配置的性能是可以接受的。但用户更关心的是，当服务器全是NVMe盘时，性能是否会受到影响。遗憾的是，我们不得不告诉他们，当添加更多磁盘时，他们很可能只会看到容量的增加，而不是性能的增加。但我们的建议并非完全没有价值。如果用户不关心小型随机IO的性能，每个OSD2个CPU核心可能是一个很好的建议。在NVMe磁盘上运行Ceph除了提高小型随机IO性能之外还有很多好处。但是，对于这个用户来说，smallrandomIO是必看的，这正是CPU资源最重要的时候。因此必须告诉他们，在添加磁盘后，他们很可能只会看到容量增加，而不是性能增加。不幸的是，这不是第一次出现这个问题，它仍然有很多麻烦。我们在2年前更新了上游Ceph文档，试图在PR(https://github.com/ceph/ceph/pull/32093)中提供更好的示例。当时我们推荐的场景需求是：1coreper200-500MB/s1coreper1000-3000IOPS但这里最重要的还是IOPS性能。本文将重点介绍Ceph小型随机IOPS性能如何随着CPU资源的增加而扩展。Nodes10XDellPowerEdgeR6515CPU1XAMDEPYC774264C/128TMEMORY128GIBDDR4NETWORK1X100GBEMELLANOXCONNECTX-6NVME6X4TBSAMSUNGPM983OSCERATSCORVENESQUEADSERASEREABLYWARESION8CEPHQUEPPHQUEPEF1.2.2.2.9.2.2.9.2.9（优越的。安装集群并使用CBT(https://github.com/ceph/cbt/)执行fio测试。除非单独说明，否则每个节点最多配置6个OSD，并使用4个fio进程使用librbd进行测试。英特尔系统上一个重要的操作系统级优化是将调整后的配置文件设置为“延迟性能”或“网络延迟”。这主要有助于避免与CPUC/P状态转换相关的延迟峰值。基于AMDRome的系统在这方面似乎不太敏感，但为这些测试调整的配置文件仍设置为“网络延迟”。测试配置基于CBT测试的Ceph集群有几处配置需要改动。首先，禁用rbd缓存，为每个OSD分配8GB内存，并在禁用cephx的情况下使用msgrV1。在最近的测试中，我们发现使用默认cephx身份验证的MsgrV2似乎给出了与使用MsgrV1相同的结果，尽管启用加密可能会导致高达30-40%的性能损失，并且服务器和客户端的CPU使用率相似甚至相同更高。RBD卷首先填充Fio预写，然后是3次4K随机读取循环，然后是iodepth=128的4K随机写入，每次持续5分钟。CBT允许OSD与其他工具或环境变量一起工作，numactl用于控制OSD在系统上可以使用多少CPUCores。初始测试是使用单个OSD和1个副本完成的。多OSD测试使用多个OSD和3个副本进行。单个OSD在多个集群上测试，ceph通过伪随机算法实现数据分布存储。不同的OSD携带不同的热点数据。某些OSD可能比其他OSD承受更大的压力，因此整体性能也可能受到影响。最终，我们可以看到Ceph集群的性能受限于集群中最慢的OSD的性能（木桶原理——最短的木片决定木桶的容量）。针对单个OSD的测试避免了这个问题，并进一步消除了额外的复制延迟和开销，以确保OSD以最高效率运行。测试单个OSD并不能代表整个集群的性能，但它确实展示了相应OSD在最佳条件下的性能。这里首先要注意的是，在2到4个核心CPU之间，性能大约提高100%。这几乎是线性增加的。但在4个CPU核心之后，增长开始放缓。从4个CPU内核增加到16个CPU内核只产生了100%的性能提升，在10个CPU内核时几乎完全趋于平稳。然而，写入性能会更高，在14-16个CPU内核时最高可达350%左右。但是CephOSD真的在测试中使用了所有这些分配的CPU内核吗？事实证明，为OSD分配更多的CPU核心可以持续提高性能，最高可达14-16个核心，但是当CPU的核心数较高时，OSD不会使用所有的核心。对于读取尤其如此。更多的CPU核心意味着更高的性能，但效率会随着您的增加而降低。但是，使用的每个CPU内核的IOPS保持相对平稳。为什么会发生这种情况，有什么限制？默认情况下，CephOSD每个OSD有80多个线程，但从资源消耗的角度来看，最重要的是：16个OSD工作线程（8个分片，每个分片2个线程）31个异步消息线程1个bluestorekey/value线程1bluestore"finisher"threadRocksDBflush(highpriority)andcompaction(lowpriority)backgroundthreads这里不用细说了（我们会在后面的文章中讨论），常用OSD的实际最大CPUCore使用率可能大约23个核心。在我们的实验中，5分钟内测试的最高利用率是4K随机写占用大约18-19个Core，没有限制OSD，禁用RocksDB的write-aheadlog。那么为什么我们在这些测试中看不到它呢？可能的答案是ceph根本无法让所有16个工作线程一直处于忙碌状态。工作线的等待时间很短。虽然一个OSD可能平均使用6或8个内核，但当它可以在短时间内突增至16个以上内核时，它可能表现最佳，而其他时候它可能只需要3-4个CPU内核。部署完整集群时，60OSD集群测试是否表现出在单个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为每个核心提供大约7500IOPS，并且根据分配给OSD的核心数量，每个核心从2400到8500IOPS不等。在写入方面，Ceph为每个使用的核心提供大约3500IOPS，为每个分配的核心提供1600到3900IOPS。这些结果比我们2年前的结果要好一些，而且我们在最新的Quincy版本中做了进一步的改进。单OSD与多OSDNVMe性能另一个常见问题是Ceph如何很好地利用NVMe磁盘。通常的测试方法是直接从本地连接的驱动器写入或读取数据。用户想知道为什么即使有大量磁盘Ceph也很慢。简单来说，Ceph确实比直接写磁盘慢，原因有很多。主要原因如下：计算crushplacement、checksum、加密、纠删码、网络开销等造成的延迟处理数据（encode/decode/etc）和分配/复制/移动线程间甚至内存中的数据岩石数据库。Ceph不只是写入数据，它还会写出关于该数据的元数据。这在执行小写操作时很重要。允许线程在没有任务要做时休眠，并在任务到达时唤醒它们。这样做是为了在低负载期间减少CPU开销，但是当线程进入休眠状态并过快唤醒时，它会对性能产生重大影响。其中一些问题如果不做任何调整和优化是很难改善的。Ceph非常容易受到网络性能的影响（尽管像dpdk这样的优化可以提供帮助）。Crush在确定数据分布时也会引入一些延迟，并且总会有一些由crc32、编码/解码等引起的额外延迟。话虽如此，单OSD和多OSD之间存在非常大的性能差异-OSD测试。上图可能有点粗糙。虽然由60个OSD组成的集群提供了大约200万次随机读取IOPS，但单个OSD能够以更高的效率提供几乎是每个NVMe4倍的性能。在写入方面，情况更接近一些，但单个OSD仍然比每个NVMe快2倍左右。在CephQuincy中，我们努力提高写路径性能。在CephQuincy版本改进和选择性RocksDB调整之间，我们在一个完整的60OSD集群上实现了4K随机写入IOPS超过40%的改进。要了解我们是如何得出这些结果的，请在此处查看RocksDB调优深入研究文章(https://ceph.io/en/news/blog/2022/rocksdb-tuning-deep-dive/)。结论最后，我们可以看到在集群级别和OSD内部仍有很大的性能提升空间。在以后的博文中，我们将深入探讨在低CPU核心数和高CPU核心数下限制性能的一些问题，以及有关如何进一步提高Ceph性能的一些想法。在此之前，每个OSD分配多少个CPUCores是一个权衡。通过为每个OSD分配2-4个CPU核心，Ceph可以在小读和小写期间充分利用所有CPU核心。当分配更多的CPU核心时（甚至每个OSD最多16+），性能可以提高，但每个添加的CPU核心的增益会降低。正常情况下，OSD可以正常稳定地使用CPUCore，但是当OSD分配的CPUCore数量较多时，OSD就无法充分利用每个CPUCore。也就是说，支出并没有带来对等的收益。因此，需要综合考虑Ceph硬件架构设计和架构设计对软件资源的支出和收益。最后，本文基于CephPacific版本。经过调优，Ceph的性能有所提升。另外需要注意的是，如果使用CephQuincy版本，结果可能会有些不同。目前的测试也是在一个新的集群上进行的。如果是运行时间较长的老集群，结果可能会有所不同。不过，这篇文章至少提供了一个思路，即CPU如何影响基于NVMe的OSD的性能。*原文链接：Ceph.io—CephOSDCPUScaling-Part(https://ceph.io/en/news/blog/2022/ceph-osd-cpu-scaling/)推荐阅读
