在《服务器NVMe调优指南：4900万IOPS、340GB/s带宽 (24x SSD)》一文中，我是以编译为主，并未加入自己较多的评论。因为在整理那份资料时，我大约有几年时间没深入测试过企业级NVMe SSD多盘服务器的性能。
最近一段时间，正好赶上手头有合适的设备，我就补充进行了一些测试验证。今天给大家分享点心得体会。
就是上面提到的文章，大家还记得测试服务器配置吗？——CPU是2颗128核的第五代AMD EPYC，给每个SSD分配了8个核心用于测试。整体上就是用192核跑出了4900万IOPS，平均每核心贡献25万多IOPS。不过正如上图，加到24块盘时并未显出遇到瓶颈，也就是说这192 个CPU核心很可能没有跑满，如果继续增加SSD或者提高单盘性能，应该还有潜力跑出更高的IOPS数字，毕竟一共有256个核心呢。
另外，上述测试尽管进行了一些调优，但还是使用传统基于中断模式的Linux内核I/O协议栈libaio，并没有用到SDPK、io_uring这些“黑科技“。
而在上面的短视频《6500万IOPS、310GB/s带宽：软RAID用了什么黑科技？》中，大家可以看到2颗64核AMD EPYC 9534 CPU利用率只有50%左右。也就是说，在用户态polling（轮询）的SPDK存储引擎下，平均每个CPU核心可以处理超过100万IOPS（这个效率我并不吃惊，因为在下面列出第一个链接里早就测到过），并且那个Demo里同时还跑着RAID处理负载呢。
扩展阅读：《SPDK实战、QoS延时验证：Intel Optane P4800X评测(5)》
《_SPDK+NVMe SSD对接Virtio支撑红包场景性能_》
注：如果使用SPDK，CPU资源最好也要准备够，一个是要面对高性能的NVMe SSD，另外轮询状态下即使没I/O访问CPU核也会100%占满。
当SPDK与libaio效率两相对比之后，就留下了一个问题或者说选择：像中断合并（Interrupt Coalescing）、SPDK、io_uring这些办法都可以提高CPU的存储I/O处理能力，而在具体应用中又会有各自的限制（后续我再撰文解释）。那么在每一款存储服务器 / CPU+SSD的配置中，用libaio先跑出的你baseline（基线性能）也是一个重要的数值——利用这个可以初步分析性能瓶颈，并为下一步加入RAID等数据保护机制后的测试做好准备。
最简单的调优，就是“不需要调优”
上图是我在一台64核单路服务器上做的测试，NVMe SSD是16块PCIe 4.0接口的——比当前最快的Gen5盘要慢一些。
这款SSD标称的最大随机读IOPS为110万。我一开始没做任何调优，保持默认BIOS设置在Ubuntu 24.04下就开始测了。随着我把测试的盘数从1-2-4-8-16这样增加，fio的IOPS结果几乎就是线性提高。只是用libaio最平常的测试，16块盘跑到1700多万IOPS。
估算一下，平均每个CPU核心贡献了27万多IOPS。请读者朋友不要直接与前文中的数据对比，因为每个平台部署的软件版本等环境不同，并且我也说了第5代EPYC那个“25万”的CPU核心并未跑满。
担心CPU核心不够？SMT多线程来助力
前面的测试看起来一帆风顺，但其实我并不是刚开始测完SSD单盘时就那么有信心。
参考下面图表，在使用libaio时（不带任何花招），每个CPU核心能处理的I/O中断数是有限的。蓝色柱形是直接用numjobs参数增加测试线程——此时会自动调用多个物理核心，我按照习惯也是从1-2-4-8线程这样增加（_注意了，其实8线程时对应的核心并未跑满_）。达到110万IOPS时我就在想，服务器上有16个NVMe SSD，而我的CPU只是一颗64核，如果给每个SSD都专门分配8个核心用，做极限IOPS压测是不够的？
但前面的测试结果大家也看到了，我直接在测试中加入更多SSD，CPU也基本没影响到IOPS的线性增加。这时想起《服务器NVMe调优指南》一文中关于同步多线程（SMT）的描述，我又做了一些验证测试，如下图中的橙色柱形：
在上面这个单盘测试中，当我把测试线程（thread，对应fio中的numjobs）从1加到2时，橙色结果是特意把2个numjobs绑定到1个CPU核心对应的2个SMT线程上（具体方法可参考《NVMe调优指南》一文）。以此类推，橙色部分Thread 4是绑定到2个CPU核的4个线程；Thread 8是绑定到4个核的8个线程。
当numjobs从1增加到2时，我们看到单纯靠SMT多线程的一对逻辑核心支撑2个numjobs，IOPS提高了64%，此时相当于用1个CPU核心能处理32万IOPS。当然相比之下，还是用2个独立硬件核心跑的性能更高。但当numjobs加到8时，这款NVMe SSD的随机读IOPS都能跑到最大值，此时8核与4核/8线程的表现就一样了（后者利用率更高）。
既然4核有能力支撑1个SSD，所以64核+16个SSD跑到1700万IOPS没有问题。而在实际测试中，我并不需要特别进行绑核等专门设置，每块盘直接使用numjobs=8参数，操作系统和硬件就能自动把资源调配好。
至少在我测试观察的部分，包括随机读/写IOPS，顺序读/写带宽，在BIOS默认的NPS=1（NUMA Node per Socket）设置下，没做任何调优就能测出理想的存储性能。就像我在《AMD EPYC 9005服务器BIOS & 工作负载调优指南》一文中曾经写过的：“最好的调优，就是不用调优”。
此时我还想起了《NVMe调优指南》写的另外一段话：
——_“第三代及之前的 AMD EPYC 处理器包含首选输入 / 输出（Preferred I/O）和宽松排序（Relaxed Ordering）设置，这些设置有助于优化网络和磁盘I/O性能。第五代 AMD EPYC 处理器（9xx4 型号）及更新型号包含了架构增强功能，默认情况下就能提供最优的网络和磁盘I/O性能，无需使用上述任何一种功能特性。”_
AMD EPYC 8004 & 9004服务器平台
接下来，我想带大家简单看一下本次测试的服务器平台。
AMD EPYC 8004系列处理器代号为“Siena”，定位比9004系列偏低，使用尺寸小一些的SP6单路CPU插槽。CPU核心数最多64。内存支持6个DDR5通道，PCIe Gen5 lane数量为96个。
Zen 4标准核心与Zen 4c高密度核心，二者微架构统一，对软件透明，只是物理实现对于不同核心密度做了优化。SMT超线程也是都支持的，这在本文存储IOPS测试中也起到了关键的作用。
参考网站 https://www.amd.com/zh-cn/par...
4个CCD（CPU die）和1个IOD在EPYC 8004（SP6）CPU上的布局
上图可以看到AMD EPYC服务器CPU前4代的代号和简要规格，每一代核心都有不小的IPC效率提升。目前又增添了去年10月发布的EPYC 9005系列（代号Turin）。
代号Genoa的EPYC 9004估计大家都不陌生了，完整的规格包括12通道内存（每CPU插槽）和128个PCI Gen5 Lane支持，也有更多核心的型号可以选择。8004系列相当于一个精简版，它的价值在于平台成本应该较低一些，TDP功耗也不超过200W。
来自存储厂商对AMD Genoa的肯定
由于企业存储产品的研发周期，一款稳定可靠的机型需要做较长时间的测试验证，以及软硬件配合调优工作。所以我们当前看到的主流存储对AMD EPYC服务器的采用，还集中在Genoa（9004）；9005的推出时间还短，不过一个有利的过渡条件是这两代CPU的Socket即主板硬件可以兼容。
下面给大家列举2款业内典型的，高性能全闪存分布式存储系统代表：
首先是IBM Storage Scale System 6000，该产品家族的灵魂，就是广受好评的并行文件系统GPFS。具体到SSS 6000的4U机箱硬件，里面容纳个2个控制器，每控制器配置了2颗EPYC Genoa 48核CPU。
如上图，SSS 6000是当前IBM Storage Scale System产品线中最新、也是最高端的一款硬件节点。关于Storage Scale/GPFS产品的性能和功能特点，我希望后续有机会再给大家分享。
上面这款产品的架构图，来自新兴的文件存储厂商VAST，这家技术的一个主要特点就是Shared-Everything架构。在之前的几年，VAST一直保持着前端元数据节点（CBox/机头）+ 后端NVMe SSD EBOF机箱（DBox）形态的硬件组合。
扩展阅读：《NVMe-oF存储扩展：EBOF、FBOF、EBOD生态详解》
而得益于NVMe-oF后端网络的成熟，VAST最近也发布了“超融合”形态的Ebox系列，它没有前后端机箱分离，而是采用了元数据服务器+SSD集成在一起的全对称节点（如果我没理解错，国内的XSKY等在架构上应该也类似）。
下表引用自《VAST Data EBox：重新定义超大规模数据中心的基础设施》，供大家参考：
先写到这里吧。按照原计划，后续我还想给大家分享一些软RAID性能对比、优化相关的内容。敬请继续关注：）
END
作者：唐僧 huangliang
原文：企业存储技术
推荐阅读
- zStorage 分布式存储系统的性能分析方法
- MLPerf Llama大模型推理测试：一款GPU独战NVIDIA群雄
- 反转：Dell 单路 EPYC 9005 服务器 CPU 支持到 400W
- 分布式存储：基于硬盘的 RAFT 状态机实现方法与挑战
欢迎关注企业存储技术极术专栏，欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
