在《
服务器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)
》
《
Linux
C 性能优化实战（基于SPDK框架）
》
《
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/partner/articles/epyc-8004-purpose-built-efficiency.html
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
：重新定义超大规模数据中心的基础设施
》，供大家参考：
