设计工具
存储

探讨:采用美光 6500 ION 的 Cassandra 性能

Ryan Meredith | 2023 年 7 月

Apache Cassandra™ 是一个 NoSQL 数据库,用于在全球范围内存储大量数据。1我的团队最近用美光 6500 ION 测试了 Cassandra,将其性能与竞争对手的 QLC(四层单元)驱动器进行比较,您可以在我们最近发布的技术简报中找到这些结果。

在测试 Cassandra 时,我们使用基于 eBPF2 的 Linux NVMe 跟踪工具,深入了解工作负载到达磁盘时的输入/输出(IO)模式。我们发现了一些有趣的洞察信息。

平均绩效

使用基准测试工具测试应用程序时,通常会将测试期间的平均关键绩效指标(KPI)作为结果进行共享。虽然这在提供系统扩展和性能的广泛视图方面很有价值,但并不能完全说明问题。以下是我们结果的一个示例:该结果展示了在一系列测试中,随着 YCSB 线程数的增加,性能有了显著提升,服务质量(QoS)延迟3显著降低。数据点表示在 8、16、32、64 和 128 个 YCSB 线程下进行的四次 20 分钟测试运行的平均性能。

Cassandra YCSB:图表:50% 读取/50% 更新——平均读取延迟与 YCSB 操作数/秒

然而,当我们使用 iostat 等标准 Linux 工具来查看平均磁盘吞吐量时,性能似乎很低。

在 32 个 YCSB 线程下,美光 6500 ION 的测试平均读取速度为 357 MB/秒,写入速度为 136 MB/秒。NVMe 固态硬盘肯定要比这快吗? 到底发生了什么?

到底发生了什么? 在 32 个线程下,YCSB 执行 50% 读取/50% 更新的工作负载。

从工作负载跟踪中,我们捕获了存储设备活动的摘要,这提供了 20 分钟运行时间内存储密集型工作负载的情况:

 

Cassandra,YCSB 执行 50% 读取/50% 更新

6500 ION

读取块大小

100% 4 KB

读取的 GB 总数

680 GB

写入块大小

74% 508 KB-512 KB

写入的 GB 总数

255 GB

丢弃块大小

80% > 2 GB

丢弃的 GB 总数

69 GB

按 IO 计数计算的读取百分比

99.6%

按容量计算的读取百分比

68%

按 IO 计数计算的写入百分比

0.4

按容量计算的写入百分比

25%

按 IO 计数计算的丢弃百分比

0%

按容量计算的丢弃百分比

7%

 

块大小

工作负载的 IO 大小(块大小)将对其性能产生巨大影响。在这里,我们看到 100% 的 4 KB 读取操作,以及大部分 508 KB 和 512 KB 写入操作,其中穿插着许多较小的写入操作。

图表:100% 4 KB 读取操作,以及大部分 508 KB 和 512 KB 写入操作

吞吐量

从时间序列数据来看,我们看到读取速度最大为 518 MB/秒,平均值为 357 MB/秒,这表明读取速度稳定。平均吞吐量为 91,000 次每秒读写操作次数(IOP),这对于 NVMe 驱动器来说很容易吸收。

6500 ION 4 KB 读取操作:图表显示的最大 IOP 为 133,000,平均 IOP 为 91,000

写入速度很有趣,因为我们看到峰值高达 5.6GB/秒,接近 6500 ION 的最大顺序性能。Cassandra 的写入工作负载是突发式的。主要原因是 memtable flush 命令将内存中的更新卸载到磁盘,并将尽快写入。结果是,2 GB/秒至 5.6 GB/秒的突发写入与 136 MB/秒的平均吞吐量之间存在巨大差异。

6500 ION 写入操作:图表显示的最大值为 5.6 GB/秒,平均值为 136 MB/秒

延迟

在查看延迟时,我们看到读取的延迟峰值约为 40 毫秒,写入的延迟峰值约为 90 毫秒。写入结果是有意义的,因为会周期性出现大量大型 IO(512 KB)写入。读取操作都是 4 KB 大小,因此发生了一些阻塞现象,导致读取延迟激增。

从固态硬盘的角度来看,这些延迟可能令人担忧,因此我们分析了固件中的 OCP 延迟监控日志,以确定这些延迟是系统级别的。在执行 memtable flush 命令期间,队列会快速填充,并且系统会不断堆积。但是,在此工作负载期间,固态硬盘未报告延迟异常值(> 5 毫秒)。

6500 ION 读取操作:100% 4 KB IO,最大延迟 50 毫秒
6500 ION 写入操作:图表显示 IO 高达 512 KB,最大延迟为 90 毫秒

队列深度

最后,系统观察到的队列深度有一个有趣的节奏,从 20 跳到 200,甚至有时候一些大的峰值会达到 800 队列深度。

6500 ION 队列深度:memtable flush 导致系统队列深度瞬间增加到 800

这种行为与我们从大量大块写入中看到的延迟效应一致。memtable flush 命令向磁盘写入大量数据,导致队列深度增加。这种较高的队列深度可能会延迟部分 4 KB 读取 IO,从而导致发生系统级延迟峰值。完成 memtable flush 操作后,Cassandra 会发出丢弃命令来清除已删除的数据。

那我们学到了什么?

平均应用程序吞吐量、延迟和磁盘 IO 提供了一个很好的视图,可以比较一个固态硬盘的性能与另一个固态硬盘的性能,或者衡量主要硬件或软件变化对性能的影响。

在分析平均磁盘 IO 时,Cassandra 等一些应用程序可能看起来对存储性能不敏感,在 iostat 等工具中会看到较低的平均吞吐量。这就忽略了这样一个事实,即固态硬盘以高队列深度尽快写入大块数据的能力对 Cassandra 的性能至关重要。为了真正了解磁盘级别的工作负载,我们必须深入研究平均值背后的故事。

© 2023 Micron Technology, Inc. 保留所有权利。所有信息均“按原样”提供,不含任何类型的质保。产品仅保证符合美光的生产数据表规格。产品、计划和规格如有变更,恕不另行通知。若印刷或照片出现遗漏或错误,Micron Technology, Inc.(美光科技股份有限公司)恕不负责。Micron、Micron 徽标和所有其他 Micron 商标均为 Micron Technology Inc.(美光科技股份有限公司)的财产。所有其他商标分别为其各自所有者所有。修订版 A 01/2023 CCM004-676576390-11635

美光存储解决方案架构总监

Ryan Meredith

Ryan Meredith 担任美光存储业务部门数据中心工作负载工程总监,负责测试新技术,助力美光在 AI 和 NVMe-oF/TCP 等领域,以及全闪存软件定义存储技术方面树立思想领袖地位并提升知名度。