A5数据香港双路EPYC服务器，2×1.92TB NVMe Gen4存储I/O性能看哪些指标？

磁盘顺序读取速度很高，数据库提交却仍然变慢；随机读IOPS看起来不错，高峰期接口仍出现长尾延迟。这两种现象并不矛盾。评估A5数据香港双路EPYC服务器的2×1.92TB NVMe Gen4存储，不能只看一个“跑分”：应同时测试顺序吞吐、随机IOPS、低队列深度延迟、P95/P99尾延迟、同步写入延迟，以及持续负载下的性能变化。

这套配置的核心问题是：两块SSD以什么方式组织，面对目标业务能提供多少满足延迟要求的有效I/O能力，以及双路CPU、内存、NUMA拓扑和网络是否先成为瓶颈。下面以该配置为评估对象说明测试方法；SSD具体型号、固件、接口链路、阵列方式和可用容量，应以实际交付信息为准，不预设实测结论。

测试目标：把业务需求变成可验收的负载

不同业务，关注的存储能力不同

“NVMe Gen4”说明接口代际，但不能单独推导出数据库性能。同样的磁盘，在大文件读取、事务日志写入和大量小文件访问中，会呈现不同的瓶颈。

表中的块大小和读写比例是起始测试点，不是所有业务的固定标准。数据库页大小、日志批量提交方式、应用缓存命中率，都可能改变实际落盘负载。

对双路EPYC服务器尤其要注意：较多CPU核心可以支撑更多工作线程，但线程增加并不必然提升存储表现。磁盘接近饱和后，新增并发通常先转化为排队时间，而不是等比例增加IOPS。

两块盘要分别看单盘能力和最终交付形态

2×1.92TB不等于一个天然具备固定性能的3.84TB存储池。容量组织方式直接决定测试对象。

这里的TB按十进制计算。1.92TB约为1.75TiB，3.84TB约为3.49TiB；操作系统显示值还会受到分区、文件系统和预留空间影响。容量显示差异不能直接认定为少配了硬盘。

两块SSD的性能不能简单乘二。 独立盘、镜像和条带的请求分发机制不同，还可能受共享PCIe路径、CPU处理能力和文件系统限制。RAID也不能替代备份。

指标含义：把速度、延迟和并发放在一起看

IOPS与吞吐量必须绑定块大小

IOPS表示每秒完成的I/O请求数，吞吐量表示每秒传输的数据量。两者通过请求大小关联：

吞吐量＝IOPS×每次I/O的数据量。

例如，4KiB随机读达到100,000 IOPS时：

• 每次请求为4,096字节。
• 每秒数据量为409,600,000字节。
• 按十进制计，约为409.6MB/s。
• 按二进制计，约为390.6MiB/s。

因此，4KiB随机读的几百MB/s与1MiB顺序读的数GB/s，不能直接比较优劣。前者可能更接近数据库索引访问，后者更接近大文件扫描。

测试报告至少应把“块大小、读写模式、IOPS、带宽、并发、延迟”放在同一组记录中。只留下一个带宽数字，会丢失解释性能所需的条件。

延迟要区分平均值、尾部和持久化语义

平均延迟描述整体趋势，P95、P99和P99.9描述慢请求的分布位置。P99为2ms，表示约99%的已采样请求在2ms以内完成，并不意味着所有请求都低于2ms。

对在线服务，平均值通常不够。一次业务请求可能串行触发多次存储访问，偶发慢I/O就可能放大接口响应时间。但多个I/O的P99不能直接相加，得到业务请求的P99；应结合调用链或事务压测验证。

使用fio时，还要分清：

• slat：提交阶段延迟，包括请求准备及提交相关开销。
• clat：提交后到完成的延迟。
• lat：fio统计的整体I/O延迟。

比较不同测试时，应使用相同字段，而不是把一份报告的clat与另一份报告的lat混在一起。

普通写入完成也不一定等于业务所需的持久化完成。数据库日志提交应结合fsync、fdatasync或数据库自身提交机制测试。direct=1用于绕过文件数据页缓存，不等于自动启用同步持久化，也不能证明SSD具备掉电保护。相关能力仍需核对型号资料、软件栈及其持久化语义。

并发不是越高越好

队列深度表示允许同时在途的请求数量。fio中，iodepth与numjobs共同影响总并发上限；例如4个任务、每个任务深度16，配置上限约为64，但实际达到的深度还取决于I/O引擎和负载。

建议从低并发向上逐级测试，例如总队列深度1、4、16、32、64，而不是只展示高队列下的峰值。

稳定状态下，可以用以下关系作一致性检查：

平均在途请求数≈每秒完成请求数×平均响应时间。

例如50,000 IOPS、平均响应时间0.4ms，对应约20个在途请求。这里必须使用同一统计边界内的平均值，不能用P99代替平均延迟。

低队列深度揭示单次访问成本，高队列深度揭示设备处理积压请求的能力。在线业务通常更需要找到吞吐与尾延迟之间的平衡点。

影响变量与采样：怎样让结果可复现

固定硬件、系统和数据状态

双路EPYC平台需要额外关注NUMA拓扑。两个CPU插槽分别关联本地内存及部分PCIe设备，测试线程、内存分配和SSD所在节点不一致时，可能增加跨节点访问。

开始测试前，至少记录以下条件：

• SSD与链路：型号、固件、PCIe实际协商代际及宽度、温度、健康状态、累计写入量。
• 存储组织：独立盘或阵列、文件系统、挂载参数、测试文件所在设备。
• 计算资源：CPU型号、双路拓扑、内存容量、CPU频率策略及虚拟化限制。
• 数据状态：盘内占用率、测试区域大小、此前写入负载、是否刚执行过空间回收。
• 业务干扰：后台备份、数据库检查点、日志轮转、监控采集和其他读写任务。

Gen4标签不保证设备始终运行在预期链路状态。槽位连接、转接设备和平台配置都可能影响实际带宽，应核对协商结果。

NUMA对照测试则应一次只改变一个变量：先保持负载一致，再比较默认调度与本地CPU、内存绑定后的结果。不应直接把“绑定核心”写成普遍优化结论。

按负载矩阵测试，不把单次峰值当作成绩

基础测试可以分成四组：

1. 低并发随机读：4KiB、队列深度1和4，观察基础延迟及CPU开销。
2. 随机读写并发阶梯：逐步提高并发，记录吞吐、P99和实际队列深度。
3. 持续顺序读写：使用1MiB等较大块，观察带宽是否出现阶段性下降。
4. 业务对应测试：增加同步写、数据库事务，或前台读与后台备份并行的负载。

读70%、写30%只是可用于比较的参考组合。业务实际为读95%、写5%时，应增加对应测试，不能用参考组合代替验收。

读写混合报告也应分别查看读延迟和写延迟。一个合并平均值可能掩盖“读取正常、写入尾延迟明显升高”的情况。

用预热、重复和时间序列避免误判

可复现的采样流程可以这样安排：

1. 核对设备、阵列和健康状态，确认测试不会影响生产业务。
2. 使用固定测试区域，记录文件大小与磁盘占用率。
3. 为每组负载安排预热，再进入正式统计窗口。
4. 每秒采集存储、CPU和内存指标，同时保留fio完整输出。
5. 每组至少重复3轮，记录中位水平、波动范围及各轮尾延迟。
6. 对持续写入和混合负载延长测试，观察是否存在温升、缓存变化或后台整理导致的性能转折。

例如，预热60秒、正式统计300秒可用于初步随机读比较；持续写入可先安排20～30分钟观察。但固定时间本身不是“已经稳定”的证据，应以时间序列是否仍在变化判断。

P99.9需要足够多的完成请求才有解释价值。尾部样本很少时，百分位容易波动。报告应保留总I/O数量，也不宜直接平均多轮P99来代表合并后的P99；可以展示各轮分布，或在保留样本后按正确方式重新统计。

一个只读随机读测试示例

以下示例适用于安装了fio的Linux系统，使用libaio引擎。测试文件必须已经存在，并位于待测文件系统；路径只是示例，不应指向原始磁盘或生产数据库文件。

测试前确认文件和挂载位置：

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
findmnt -T /mnt/io-bench/read-test.bin
stat /mnt/io-bench/read-test.bin

随后执行：

fio \
  --name=randread-qd1 \
  --filename=/mnt/io-bench/read-test.bin \
  --allow_file_create=0 \
  --readonly \
  --rw=randread \
  --bs=4k \
  --ioengine=libaio \
  --direct=1 \
  --iodepth=1 \
  --numjobs=1 \
  --time_based=1 \
  --ramp_time=60 \
  --runtime=300 \
  --group_reporting=1 \
  --percentile_list=50:95:99:99.9 \
  --output-format=json \
  --output=randread-qd1.json

该命令不会向测试文件写入数据，但仍会产生存储负载，可能影响同机业务；输出文件也应使用新的文件名，避免覆盖已有报告。测试文件应覆盖有代表性、已经写入的数据区域，不能把稀疏文件的空洞读取当成SSD读取能力。

测试期间可在另一终端采样。以下命令需要安装sysstat：

iostat -x -y 1
mpstat -P ALL 1

提高iodepth可以构成并发对照，但应核对fio实际队列深度分布。不要直接把示例改成写入后在生产盘运行。写测试仅适用于已确认可覆盖的专用测试区域，并应事先备份、验证恢复能力、安排停测条件；停止测试并不能恢复被覆盖的数据，恢复需依赖测试前的备份或有效快照。

结果解释：识别有效性能，而不是追逐峰值

从并发曲线找吞吐与延迟的转折点

下面是一组用于说明方法的参考数据，不代表A5数据该配置的实测表现。各组均为相同测试区域、4KiB随机读，仅改变总队列深度。

如果业务为存储层设定的P99预算是2ms，那么示例中的81,000 IOPS不能作为该业务的可用容量。更有意义的是满足延迟预算的运行区间，并在该区间内保留余量。

这就是“有效IOPS”的含义：在指定块大小、读写比例、持久化方式、并发和尾延迟约束下，能够持续完成的请求数。

用CPU、内存和I/O监控交叉判断

吞吐没有继续增长，不一定意味着SSD本身已到上限。

iostat中的await可以辅助观察请求等待与完成耗时，但不是设备内部延迟，也不能替代fio的P99。NVMe能够并行处理多个请求，%util接近100%不必然等于性能已完全饱和；iowait较低也不能证明应用没有等待存储。

内存同样需要纳入判断。缓存命中率高时，业务实际落盘需求可能较小；工作集超过内存后，物理读取会明显增加。因此，应同时保留设备能力测试和真实业务缓存状态下的测试，不能混成一个成绩。

香港部署的网络体验与本地I/O分开验收

本地fio测试回答的是服务器内部存储能力，不包含用户到香港机房的链路延迟。远程接口响应时间还包括网络往返、应用计算、连接处理以及数据库访问。

对于文件传输，端到端速度会受最慢环节限制。例如1Gbps链路的理论数据速率是125MB/s，尚未扣除协议开销。按十进制计算，100GB数据即使持续达到这个理论速率，也需要：

100GB×8×1,000÷1,000Mbps＝800秒，约13.3分钟。

即使本地SSD读取更快，也无法突破该链路的理论带宽。验收时应分别保留本地磁盘测试和目标访问地区的端到端测试，避免把网络限制误归因于NVMe。

围绕数据库、接口服务与容器混合负载，A5数据的香港AMD EPYC服务器提供单路、双路平台及不同内存、NVMe存储组合，为并行任务处理、数据库缓存和业务数据读写提供资源基础。香港产品另有CN2与国际带宽方案，将本地计算、存储资源与面向不同访问人群的网络需求衔接，覆盖业务后台、多任务运行及数据服务等部署场景。

决策边界：用延迟预算、容量和复测条件判断是否够用

适用性取决于业务负载，而非配置名称

对于数据库、容器混合负载和高频日志写入，这套配置是否合适，应以低延迟随机I/O、同步写和持续负载表现判断。大文件业务则更应关注顺序吞吐、网络能力及容量增长。

如果业务要求磁盘级冗余，应评估RAID1或应用层冗余方案，不能为了更高条带吞吐忽略故障边界。若计划把日志与数据分盘，还应验证两盘同时工作时的性能，而不是只分别测试空闲状态下的单盘成绩。

写密集业务需要额外核对SSD耐久度。以持续25MB/s逻辑写入为例：

25MB/s×86,400秒＝2,160,000MB/天，约2.16TB/天。

镜像方式下，每块盘都要承接一份逻辑写入，底层还可能增加元数据写入和写放大。这个估算不能直接转换为寿命承诺，应结合具体型号的耐久规格、累计写入量和长期监控判断。

用业务请求量估算所需I/O，再保留余量

可以先用一个简单模型建立容量需求：

所需物理IOPS≈每秒业务请求数×每个请求平均落盘I/O次数。

例如，业务目标为2,000请求/秒，每个请求平均发生6次物理I/O，则基础需求约为12,000 IOPS。还应加入事务日志、检查点、备份、索引维护及流量突发带来的额外负载。

这里的“物理I/O次数”应来自业务监控或压测，不能把SQL条数直接当成磁盘请求数。缓存、合并写入和预读都会改变对应关系。

运行余量也不宜机械取固定比例。可先将计划负载设在满足P99目标的持续能力之下，再通过突发流量和后台任务叠加测试，验证余量是否足够。

容量与性能应共同决定扩容和复测时间

容量规划可以按以下口径计算：

预计需求＝当前有效数据＋规划期增长量＋临时处理空间＋快照或备份占用＋运维余量。

其中，两块独立盘要分别计算需求；镜像按约1.92TB标称空间规划；条带按约3.84TB规划，同时承担无磁盘冗余的边界。数据库重建索引、批量导入和备份暂存需要的额外空间，应按实际流程单独估算。

复测不必等到业务明显变慢才进行。SSD型号或固件变化、阵列调整、文件系统改动、CPU与NUMA策略变化、占用率明显上升，或后台任务模式改变，都应触发相同口径的复测。

最终验收记录应保留：设备与拓扑信息、测试数据状态、块大小与读写比例、并发、持久化方式、预热与采样时长、IOPS与带宽、P95/P99、CPU及温度时间序列。对A5数据香港双路EPYC服务器而言，可复核的判断不是一个孤立峰值，而是在目标占用率和后台负载下，持续满足业务延迟预算的存储能力与剩余空间。