Ceph：实现 1 TiB/s 性能实践

早在 2023 年，就有一家相当前沿的公司找到Clyso，希望将他们支持 HDD的Ceph集群过渡到10PB的NVMe集群。他们对此非常感兴趣。他们对RBD、RGW或CephFS没有特殊需求。同时，他们也有自己的硬件设计规范，但在实际购买之前，他们主动向我们寻求⼀些建议。他们的要求稍微略有不同。集群必须分布在 17 个机架上，每个机架有4U的可用空间。电源、冷却、密度和供应商等等都是影响因素。新节点需要在不中断服务的情况下迁移到现有的新集群中。然而，目前的网络已经建成，而且是⼀个比较大型的网络。这是我见过的速度最快的网络之一，在本次测试的环境中，不存在任何的网络瓶颈。我们也非常希望协助对方完成集群的建设。另外，在正式上生产之前，我们也需要进行充分的测试以及试运行。这对我们而言，这将是一个特别好的机会来在这样的一个物理环境下去充分优化 Ceph 集群。接下来的内容描述了我们如何构建和测试该集群，以及我们能够将其优化到何种程度。

当客户第一次与 Clyso 接触时，他们提出了一种在17个机架上分布 34 个双插槽2U节点的配置。我们提供了多个供应商的几种备选配置，特点是配置相对小一些。最终，他们决定采用我们设计的基于戴尔的架构，该架构不但拥有几个比较关键的优势，同时报价也比原始配置便宜了大约13%。新配置的每个OSD的内存容量更小（每个OSD的内存容量仍为12GiB），但内存吞吐量更快。它还提供了更多的CPU资源、更大的网络总吞吐量、更简单的单插槽配置，并使用了最新一代的 AMD 处理器和DDR5内存。通过使用更小的节点，我们将节点故障对集群恢复的影响减小了一半。

客户表示，他们希望将每个机架的新增功耗限制在1000-1500瓦左右。如果每个机架有4个这样的节点，那么总TDP估计至少为1120瓦，再加上基本用电量、CPU超负荷峰值和低电源效率。虽然在负载情况下，我们可能会有点超负荷，但预计不会超出可接受的范围。如果情况更糟，我们估计通过降低处理器的CTDP，每个机架可以减少，大约100 瓦。

该系统的规格如下所示：

使用1U 戴尔服务器的另一个好处是，它们基本上是 David Galloway 和我们为上游 Ceph性能实验室设计的系统的更新换代产品。在过去的几年中，这些系统已经在各种文章中进行过测试。结果发现，在测试过程中出现了一个影响性能的重大问题，该问题并未影响上游实验室的上一代硬件，但却影响了这⼀新硬件。我们稍后会详细讨论这个问题。

在不涉及太多细节的情况下，我们想重申的是，客户的网络配置设计得非常好，速度也相当快。所有17个机架的总吞吐量足以让这么大规模的集群真正发挥其作用，从而无须考虑网络的瓶颈。

为了进行机测试，部署了临时Ceph集群并使用CBT启动了FIO 测试。

我们同时对 CBT 进行了如下配置，以便在部署Ceph时修改默认配置。OSD被分配为8GB osd_memory_target 。在生产中，可以接受更高的osd_memory_target  配置参数。客户不需要测试块或 S3 工作负载，因此可能会认为 RADOS bench 是推荐的基准测试工具。

但是，根据我们的经验，使用 RADOS bench 进行大规模测试非常困 难。在给定线程数的情况下，很难确定需要多少实例才能使集群达到饱和。过去我们曾遇到过需要多个 并发池来扩展性能的问题。但我们手头也没有任何现有的RADOS基准测试可供比较。相反，我们选择使用与上游实验室相同的librbd支持 FIO 测试来进行测试。这样，我们就可以将集群划分为更小的块， 并将结果与之前公布的结果进行比较。FIO也是众所周知、值得信赖的⼀款存储性能测试软件。在 FIO中使用 librbd 引擎（与使用内核RBD的FIO相比）的一个主要好处是，不会出现挂载点超时可能需要重启系统的问题。我们没有 IPMI 访问该集群的权限，而且完成测试的时间很紧。因此，我们最 终跳过了内核 RBD 测试。不过，根据之前的测试结果，如果有足够的客户端，我们预计总体性能会大致相同。不过，我们还是测试了3X副本和6+2擦除编码。我们还使用以下Ceph选项在未加密和安全模式 下测试了 msgr V2：

ms_client_mode = securems_cluster_mode = securems_service_mode = securems_mon_client_mode = securems_mon_cluster_mode = securems_mon_service_mode = secure

OSD 允许使用节点上的所有 CPU 内核资源。FIO 被配置为首先使用大量写⼊预填充 RBD 卷，然后进行4MB 和 4KB IO 测试，每个测试持续 300 秒（调试运行期间为 60 秒）。禁用了某些后台进程，如刷新、深度刷新、PG自动扩展和 PG 平衡。

在本文稍后部分，您将看到一些令人惊讶的 PG 数值测试。这是有意为之。我们从以前的上游实验室测试 中了解到，PG 数量会对性能产生巨大影响。其中部分原因是由于 PG 数量较低时随机分布的结果。这种 情况可以通过额外的平衡得到部分缓解。另外，较少的原因是 OSD 内部的 PG 锁争用问题。

我们观察到，在速度非常快的集群上，PG 锁争用会对整体性能产生重大影响。遗憾的是，在不增加 PG 数量的情况下，这种情况不太容易缓解。PG 数量到底有多重要？

只需 60 个 OSD，随机读取性能就可在使用 3X 的 RBD 池上扩展到 16384 个 PG。写入的峰值要早得 多，但仍可从高达 2048 个 PG 中获得较大的好处。

有一点很明确：我们不应该盲目地将生产的Ceph集群配置为使用像我们在这里测试的那样高的PG数量。当考虑到Ceph中对PG日志长度和PG统计更新等⼀些其他默认设置时候，这会显示的尤其重要。

不过，在此，我们确实想鼓励社区思考每个OSD100个PG是否仍有意义。

在控制开销和内存使用量的 同时，我们需要做些什么来提高每个OSD的PG数量。在未来，每个OSD拥有1000个PG并不是什么 稀罕事，PG日志会根据每个池自动缩放，而PG自动缩放则是⼀种较少使用的操作。

我们在感恩节后一周首次登录了新硬件。我们的计划是用一两周时间进行烧机验证测试，然后将新硬件 集成到现有集群中。如果一切按计划进行，我们希望能在新年前完成迁移。遗憾的是，我们一开始就遇 到了麻烦。最初的底层性能测试看起来不错。

Iperf网络测试表明，每个节点的速度略低于200Gb/s。对几个节点的随机抽样显示，NVMe硬盘的基线性能还算合理。我们很快发现的⼀个问题是，所有68个节点上的操作系统都地部署在2个OSD硬盘上，而不是内部的戴尔BOSSm.2 启动硬盘上。我们原计划将30个OSD 配置（3个节点，每个节点10个OSD）的结果与上游实验室的结果（5个节点，每个节点6个OSD）进行比较。但我们最终测试了每个节点8个NVMe 驱动器。即使减少了OSD 数量，第一批Ceph结果也远远低于我们的预期。

唯一可以接受的结果是随机读取，但仍然不是很好。显然，这里面有问题。我们停止了 3 节点测试，开始研究单节点甚至单 OSD 配置。 

就在这时，事情开始变得异常起来。

当我们在集群中的单个节点上运行8-OSD 和 1-OSD 测试的不同组合时，我们看到了截然不同的行为， 但经过几天的测试，我们才真正了解了我们所看到的模式。最初在单OSD测试中表现良好的系统，在多 OSD 测试后不再表现良好，几个小时后才又开始正常工作。8-OSD 测试偶尔会出现性能良好的迹象，但 随后的所有测试都表现糟糕，直到系统重新启动。最终，我们发现了⼀种新启动模式，可以在集群的不 同节点上重复：

最初的单OSD测试在大型读取和写入方面表现出色，其吞吐量几乎与我们直接针对硬盘运行FIO测试时 看到的相同。然而，我们一开始运行8-OSD测试，就发现性能有所下降。随后的单OSD测试性能继续下降，直到几个小时后才恢复正常。只要不进行多OSD测试，性能就能保持较高水平。 

令人困惑的是，在直接针对硬盘运行FIO 测试时，我们无法调用相同的行为。同样令人困惑的是，在 8 OSD 测试中，单个 OSD 的 CPU 占用率明显高于其他 OSD：

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND511067 root 20 0 9360000 7.2g 33792 S 1180 3.8 15:24.32 ceph-osd515664 root 20 0 9357488 7.2g 34560 S 523.6 3.8 13:43.86 ceph-osd513323 root 20 0 9145820 6.4g 34560 S 460.0 3.4 13:01.12 ceph-osd514147 root 20 0 9026592 6.6g 33792 S 378.7 3.5 9:56.59 ceph-osd516488 root 20 0 9188244 6.8g 34560 S 378.4 3.6 10:29.23 ceph-osd518236 root 20 0 9390772 6.9g 33792 S 361.0 3.7 9:45.85 ceph-osd511779 root 20 0 8329696 6.1g 33024 S 331.1 3.3 10:07.18 ceph-osd516974 root 20 0 8984584 6.7g 34560 S 301.6 3.6 9:26.60 ceph-osd

OSD 在负载情况下的时间曲线显示，在 io_submit 阶段花费了大量时间，这就是我们通常看到的内核 因驱动器队列已满而开始阻塞的情况。

+ 31.00% BlueStore::readv(boost::intrusive_ptr<ObjectStore::CollectionImpl>&,g... + 31.00% BlueStore::_do_readv(BlueStore::Collection*,boost::intrusive_ptr<Blu...  + 24.00% KernelDevice::aio_submit(IOContext*)  |+ 24.00% aio_queue_t::submit_batch(std::_List_iterator<aio_t>,std::_List_it...  | + 24.00% io_submit  | + 24.00% syscall

为什么运行8OSD测试会导致内核在以后的单OSD测试中开始阻塞 io_submit？这说不通。起初，我们 怀疑是节流。我们看到，在BIOS 中的默认冷却配置文件下，CPU上的几个核心复合温度高达96摄氏度。我们推测，可能是在8-OSD测试过程中，CPU或NVMe驱动器达到了热极限。这可能会使系统在一段时间内处于降级状态，然后才能恢复。遗憾的是，这⼀理论并未得到证实。AMD/Dell 确认，即使在 这样的温度下，我们也不应该遇到节流问题，而且我们还通过让风扇以 100% 的速度运行系统和降低处 理器的 CTDP 来推翻了这一理论。这些改变使系统在负载情况下始终保持在70摄氏度左右，但问题依然 并未得到解决。

在一个多星期的时间里，我们检查了所有配置，包括BIOS设置、NVMe多路径、底层 NVMe 调试、更 改内核/Ubuntu版本，以及检查我们能想到的所有内核、操作系统和 Ceph 设置。但这些都没能完全解 决问题。

我们甚至在 "good "和 "bad "单OSD测试中执行了blktrace 和 iowatcher分析，可以直接观察到缓慢的 IO 完成行为：

这时，我们开始让硬件供应商参与进来。但最终证明没有必要。经过⼀次小修和两次大修，一切都回到了正轨。

第一个修复方法很简单，但只能让我们的性能提高 10-20%。很多年前，有人发现（我记得是 Nick Fisk 还是 Stephen Blinick 发现的），Ceph 对 CPU c 状态转换带来的延迟非常敏感。对这些节点的 BIOS 进行快速检查后发现，它们并没有运行在禁用 C 状态的最高性能模式下。这是一个很好的结果，但还不足 以达到我们想要的结果。

当我们深入研究上图所示的blktrace结果时，我们有95%的把握认为，要么是 NVMe 硬盘出了问题，要么是与PCIe root complex 有关，因为这些系统中没有PCIe交换机。我们翻阅了大量的技术手册， 试图找到调试/配置该硬件的方法。此时，一位工程师主动提供了帮助。我们为他搭建了一个测试环境， 这样他就可以在一组备用节点上重复一些相同的测试，最后，直接得到了我们最想要的结果。

我们之前主要关注的是 wallclock 配置文件，同时也在深入调试硬件，而他则是想了解内核方面是否有些问题（现在回想起来，这显然是正确的！）。他在一次异常的运行过程中运行了一个性能分析，发现 了一个非常敏锐的问题：

   77.37% tp_osd_tp [kernel.kallsyms] [k]native_queued_spin_lock_slowpath            |            ---native_queued_spin_lock_slowpath               |                --77.36%--_raw_spin_lock_irqsave                          |                          |--61.10%--alloc_iova                          |          alloc_iova_fast                          |          iommu_dma_alloc_iova.isra.0                          |          iommu_dma_map_sg                          |          __dma_map_sg_attrs                          |          dma_map_sg_attrs                          |          nvme_map_data                          |          nvme_queue_rq                          |          __blk_mq_try_issue_directly                          |          blk_mq_request_issue_directly                          |          blk_mq_try_issue_list_directly                          |          blk_mq_sched_insert_requests                          |          blk_mq_flush_plug_list                          |          blk_flush_plug_list                          |          |                          |          |--56.54%--blk_mq_submit_bio

在更新IOMMU映射时，内核会花费⼤量时间争夺spin lock。

他禁用了内核中的IOMMU，在8节点测试中立即看到性能大幅提升。我们多次重复这些测试，发现4MB读/写性能大大提高。不过，4KB随机写入仍然存在问题。

经过其他人协助后， IOMMU 问题得到了解决。经过前两次修复后，4K 随机写入性能有所改善，但仍明 显低于上游实验室（即使节点/驱动器数量减少）。我们还注意到，RocksDB 的压缩速度比预期的要慢得 多。之前有两个重要的案例呈现出类似的情况，似乎与此有关：

 1. 如果没有正确编译 TCMalloc 支持，Ceph 的运行速度会非常慢。 

 2. 如果不使用正确的 cmake 标志和编译器优化编译，Ceph 的运行速度会非常慢。

这位客户一直使用Ceph Ubuntu 软件包，我们在这里也同样使用它们（而不是自编译或使用容器中的 cephadm）。我们检查了 TCMalloc 的编译情况。这就排除了第一个问题。接下来，我们查看了 17.2.7 Ubuntu 软件包的上游构建日志。这时我们才注意到，事实上，我们在编译 RocksDB 时并没有使用正确 的编译标志。虽然不清楚这种情况持续了多久，但我们早在 2018 年就遇到过⼀般的编译性能问题。

事实证明，Canonical 和 Gentoo 在看到我们 6 年前在 do_cmake .sh 中写下的说明后，都为自己的构建 修复了这个问题。很遗憾，我们的上游 Deb 构建一直以来都受到这个问题的困扰，不过，它至少不会影 响在 Debian/Ubuntu 上使用 cephadm 和上游容器的用户。在了解了问题所在之后，我们构建了定制的 17.2.7 软件包并进行了修复。压缩时间缩短了约 3 倍，4K 随机写入性能提高了一倍（虽然从图中很难看 出来）：

4KB 随机写入性能仍然低于我们的预期，但鉴于我们的 OSD 数量较少，节点数量只有原来的 3/5，每个 OSD 的内核数量也较少（但速度更快），至少现在我们的性能大致处于合理的范围内。此时，我们已临近假期。客户希望将操作系统重新部署到正确的启动驱动器上，并使用我们发现的所有修复和调整功能 更新部署。我们的计划是利用假期休息，然后在新年的第⼀周完成烧机测试。希望我们能在下周开始迁 移集群。

我们重新部署了CBT并重新创建了我们之前运行的测试。这一次，我们可以使用每个节点的全部10块硬盘。我还增加了客户端的数量，使每个 OSD的 io_depth 为128，平均保持大约1个FIO客户端。第一个3节点测试结果不错。在每个节点有10个OSD的情况下，我们的性能与之前的测试基本成正比（IE 较高）。我们知道没有太多时间进行适当的扩展测试，所以我们立即将3节点提升到10节点。还同 时增加了PG数量，并使用CBT 部署了一个新的集群。在3节点时，我们看到 4MB随机读取的速度为 63GiB/s。在10个节点时，则看到了213.5GiB/s。这几乎是 98.4% 的线性扩展。此时，事情终于有了转 机。在这个集群的 68 个节点中，只有63个在运行。其余的节点都处于停机维护状态，以修复各种问 题。我们将集群大致分成两半，一半有 32 个节点（320个 OSD），另一半有31个客户端节点，每个节点运行10 个FIO进程。我们观察了CBT 在大约7-8分钟的时间内构建集群的过程。最初的写入预填充 看起来非常好。我们以635GiB/s的速度读取数据。我们的4k随机读取IOPS突破了1500万。虽然与 单个 NVMe 驱动器相比，结果是否并不是异常高，但这是我们所见过的约 300 OSD Ceph 集群的最高数据。

我们还绘制了缩放测试的平均延迟和尾部延迟图。两者看起来一致。这可能是由于在缩放OSD的同时缩 放了PG数量和FIO客户端数量。不过，这些测试的IO量非常大。我们有如此多的客户端流量，以至于 我们很可能已经进入了⼀个拐点，即随着IO的增加，性能不会再提高，而延迟却会继续增加。

我们没有额外的客户机节点来测试集群的满负荷运行，因此唯⼀的选择就是将FIO进程与OSD放在同一个节点上。一方面，这提供了非常小的网络优势。客户端将有1/63的时间可以与本地OSD通信。另一方面，我们从以前的测试中了解到，在OSD节点上共用FIO客户端并不是没有影响的。这通常会对性能 造成影响，而我们还并不清楚这种规模的集群会受到多大的影响。

我们利用现有的63个节点构建了一个新的CBT配置。使用CBT部署集群只用了大约15分钟就启动了 所有 630 个OSD并建立了池。然后，观察结果。

大约 950GiB/s。非常非常接近我们想要的理想值。周六早上，我登录并对集群进行了一些调整：降低OSD分片和异步信使线程，同时应用Reef RocksDB 调整。正如大家所看到的，我们在提高写入性能的 同时，也略微降低了读取性能。事实上，随机写入性能提高了近 20%。进一步测试后发现， reef tunings 虽然只对写入测试有一点帮助，但似乎是良性的。更大的影响似乎来自于分片/线程的变化。此 时，我们先暂停休息一下，直到周日晚上才能再次恢复集群工作。

之前提到过，我们知道 PG 数量会影响性能。因此决定保留之前的“调整”配置，但将 PG 数量增加了一倍。

在第一组测试中，考虑到我们将客户端与 OSD 共同定位在 OSD 节点上，我降低了客户端与 OSD 的比率。现在我再次尝试扩大它们的规模。随着客户端数量的增长，4MB 随机读性能略有提升，而小随机 读 IOPS 则有所下降。一旦我们达到每个节点 8 个 FIO 进程（总共 504 个），顺序写入性能就会下降。

为了了解发生了什么，我们重新执行了写入测试，并查看了 "ceph -s "输出：

services:  mon: 3 daemons, quorum a,b,c (age 42m)  mgr: a(active, since 42m)  osd: 630 osds: 630 up (since 24m), 630 in (since 25m)       flags noscrub,nodeep-scrubdata:  pools:   2 pools, 131073 pgs  objects: 4.13M objects, 16 TiB  usage:   48 TiB used, 8.2 PiB / 8.2 PiB avail  pgs:     129422 active+clean           1651 active+clean+laggyio:  client: 0 B/s rd, 1.7 GiB/s wr, 1 op/s rd, 446 op/s wr

当我们向集群发送504个4MB写入的 FIO 进程时，一些PG就开始处于 active+clean+laggy 。

性能 急剧下降，直到工作负载完成，集群才从这种状态中恢复过来。更糟糕的是，随着时间的推移，更多的PG开始变得滞后，即使吞吐量只是集群能力的一小部分。从那时起，我们在邮件列表中发现了一些关于PG滞后的报告，以及一些可以解决这些问题的建议。目前还不清楚这些建议是否会对此处有所帮助。我们确实知道，当PG进入滞后状态时，IO会暂时中止，而发生这种情况的原因是副本没有及时确认来自主服务器的新租约。

在与其他Ceph开发人员讨论这个问题后，我们认为这可能是OSD中的锁问题，或者是租约消息与同/异步msgr 线程中的工作竞争的问题。

尽管被延迟的PG问题分散了注意力，但我们还是想重新回到如何达到 1.0TiB/s 这一目标上。我们又把PG数量增加了一倍，达到了256K，想看看这对PG滞后问题是否有任何影响。这让我们的速度稳稳地 达到了我们之前展示的曲线的上端，不过老实说，我不认为这有什么关系。我决定换回默认的OSD分区数量，并继续使用504 个FIO客户端进程进行测试。不过，我还是增加了异步消息线程的数量。有两大收获。

首先，减少到1个异步消息线程可以避免PG出现滞后，并在504个客户端的情况下实现 "OK "的 写吞吐量。但这也大大降低了4MB读取的性能。第二点：Ceph的默认设置实际上非常适合4MB读取。通过8个分片、每个分片2个线程和3个 msgr 线程，我们最终突破了 1TiB/s。下⾯是最后⼀组测 试时看到的景象：

services:  mon: 3 daemons, quorum a,b,c (age 30m)  mgr: a(active, since 30m)  osd: 630 osds: 630 up (since 12m), 630 in (since 12m)       flags noscrub,nodeep-scrub
data:  pools:   2 pools, 262145 pgs  objects: 4.13M objects, 16 TiB  usage:   48 TiB used, 8.2 PiB / 8.2 PiB avail  pgs:     262145 active+cleanio:  client: 1.0 TiB/s rd, 6.1 KiB/s wr, 266.15k op/s rd, 6 op/s wr

以及 FIO 结果图：

还有很多工作要做。到目前为止，我们所做的所有测试都是使用3X 副本，但客户会将此硬件迁移到部署 有 6+2 纠删码的现有集群中。我们需要了解一下该集群在他们将要使用的配置中的性能。

我们再次重新配置了群集，并进行了新的测试。我从之前的测试中挑选了看起来运行良好的PG/shard/client 值。性能还不错，但我们发现异步消息线程工作得非常困难。我们决定在默认值的基 础上增加线程数，看看在网络流量增加的情况下是否会有帮助。

使用4-5个异步msgr线程，我们的读取速度远远超过500GiB/s，

写入速度接近400GiB/s。但为什么使用EC时的读取速度比使用复制时慢得多？使用复制时，PG的PrimaryOSD只需读取本地数据并将其发 送到客户端。网络开销基本上是1倍。使用6+2 消除编码时，Primary OSD必须从副本中读取6个数据 块中的5个，然后才能将构建的对象发送给客户端。请求的总体网络开销大致为 (1+5/6)X*。这就是为 什么我们看到的读取性能略高于3倍复制性能的一半。写入的情况正好相反。使用3倍复制时，客户端将对象发送到主服务器，然后 Primary OSD 节点再通过网络将副本发送到两个Secondary OSD 。这将 导致3倍的总网络开销。在EC情况下，我们只需向Secondary OSD节点发送 7/8 个数据块（几乎与读取情况相同，但不完全相同）。对于大容量写入，性能实际上更快。

本文最初指出读取时必须获取7/8个数据块。但正确的值是5/6块，除非启用了快速读取。在这种情况下，应该是7/6块。

然而，IOPS则是另一回事。对于非常小的读取和写入，Ceph会联系PG 中所有参与该对象的OSD，即 使它们存储的数据与操作无关。例如，如果您正在进行4K读取，而数据完全存储在其中一个OSD的单个块中，Cep 仍会从参与条带的所有OSD抓取数据。2023年，Clyso引入了来自Xiaofei Cui的PR， 该PR为擦除编码实现了部分条带读取，从而避免了这些额外工作。效果非常显著：

虽然 Ceph 项目的核新负责人 Radoslaw Zarzynski 表示愿意帮助我们完成这项工作，但目前还不清楚我 们是否能够为 Squid 合并这项工作。

最后，我们希望让客户大致了解如果他们决定使用msgr级加密会对他们的集群产生多大影响。我们成功 地在启用了msgr v2加密的情况下运行了 3X 副本和 6+2 擦除编码测试，并将其与我们之前的测试结果 进行了比较。

影响最大的是大容量读取。它们从~1 TiB/s降⾄约750 GiB/s。其他方面的影响虽然持续存在，但幅度 较小。此时，因时间有限，我们不得不停止测试。我们希望做一些PG扩展测试，甚至内核RBD测试。不过，只能到此为止了。

测试结束后，这个集群发生了什么变化？我们对所有硬件进行了重新安装，并将新的 OSD 部署到客户现 有的硬盘集群中。Dan的 upmap 重映射脚本用于控制迁移过程，我们已经将大约 80% 的现有数据迁移 到了 NVMe 支持的 OSD。预计到下周，集群将完全迁移到基于 NVMe 的新节点上。我们选择不采用我 们在这里所做的所有调整，至少一开始不会。起初，我们将确保集群在现有配置（主要是默认配置）下 运行良好。如果客户遇到任何性能问题，我们现在就可以利用大量数据进一步调整系统。

由于本次测试过程中有大量的数据和图，因此，我们只是总结了一下其中的最重点的部分。

以下是我们在该集群上取得的最佳结果概要表：

下⼀步是什么？我们需要想办法解决写入过程中PG滞后的问题。我们不能让 Ceph 在写入操作量增加时崩溃。除此之外，我们还通过这次测试了解到，Ceph 完全能够让 2x 100GbE NIC 达到饱和。如果要进一步提高吞吐量，在每个节点使用10 个或更多 NVMe 驱动器时，我们将需要 200GbE 以上的网络。

一步提高吞吐量，在每个节点使用10个或更多 NVMe 驱动器时，我们将需要 200GbE 以上的网络。IOPS 的影响更为细微。我们知道，PG 数量会产生很大影响。我们还知道，一般 OSD 线程模型也有很大影响。每个节点的随机读取 IOPS 在 40-600K 左右时，我们总是会越到各种问题，我们在多个部署环境 中都看到过这种情况。部分原因可能是异步 msgr 与内核的交互方式，部分原因可能是 OSD 线程如何在 新工作进入分片队列时唤醒。我们过去修改过 OSD 代码，以便在重负载下取得更好的效果，但代价是低 负载延迟。最终，我们认为提高IOPS 需要多管齐下，并重写部分 OSD 线程代码。

目前，这是迄今为止公布的速度最快的单集群 Ceph，也是 Ceph 集群首次达到 1 TiB/s 的性能。同时， 我们认为 Ceph 还能做得更好。如果你有更快更好的的集群环境，我们也希望能够你们能够在自身的环 境中进行验证，然后发布相应的测试结果，同时也欢迎共享到社区。

如有相关问题，请在文章后面给小编留言，小编安排作者第一时间和您联系，为您答疑解惑。