存储与网络基准 —— fio、iperf、ib_write_bw、SPECsfs

存储和网络两条线的 benchmark 在集群验收里同样占大头——HPL 测 GPU、fio 测盘、iperf/perftest 测网。本文讲实操。

存储 benchmark 的几个层级

graph TB
  L1[块设备 / RAW
fio / iozone]
  L2[文件系统
fio + ext4/xfs/zfs]
  L3[NAS / 网络文件
SPECsfs / fio over NFS]
  L4[分布式存储
IO500 / Gluster bench / Ceph bench]
  L5[GPUDirect Storage
gdsio / NVIDIA fio plugin]
  L1 --> L2 --> L3 --> L4 --> L5

各层关注点不同。测 SSD 性能用 fio 直对块设备；测分布式文件系统用 IO500。

fio —— 块/文件存储基准事实标准

fio 是 Jens Axboe（Linux block layer 作者）写的，块/文件存储测试事实标准。

关键参数

1
2
3
4
5
6
7
8
9
10
11
12
fio \
  --name=test \
  --filename=/dev/nvme0n1 \   # 直接对块设备
  --rw=randread \              # 模式
  --bs=4k \                    # 块大小
  --iodepth=128 \              # 队列深度
  --numjobs=8 \                # 并发线程
  --runtime=300 \              # 持续秒数
  --time_based \
  --group_reporting \
  --ioengine=libaio \          # 引擎（io_uring 也常用）
  --direct=1                    # 绕过 page cache

五个标准 workload

1
2
3
4
5
seq_read：     大块顺序读     → 测带宽 GB/s
seq_write：    大块顺序写     → 测带宽 GB/s
rand_read：    4K 随机读      → 测 IOPS / 延迟
rand_write：   4K 随机写      → 测 IOPS / 延迟（写最痛苦）
70/30 mix：    70% 读 30% 写  → 模拟真实数据库

看哪几个数字

1
2
3
4
5
IOPS：      每秒 IO 操作数
bw：        带宽（MB/s 或 GB/s）
clat avg/95/99/99.9：  完成延迟分布
clat stddev：          延迟抖动（越小越稳）
util：      设备利用率（高 ≠ 满，注意 multipath）

P99/P999 延迟比平均延迟更重要——用户感知的是”慢请求的尾巴”。

一些经验值

介质 顺序读 4K 随机读 IOPS P99 延迟
7200 转 HDD 200 MB/s 100-200 10-30 ms
SATA SSD 550 MB/s 50K-100K < 1 ms
NVMe Gen4 SSD 7 GB/s 1M < 100 μs
NVMe Gen5 SSD 14 GB/s 2M < 100 μs
Optane PMem（已停产） 6 GB/s 0.5M < 10 μs

新代次（PCIe Gen5 NVMe）一颗盘 IOPS 已经够干掉传统 RAID 阵列。

跑 fio 的几个坑

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
1. direct=1 必须加
   → 不加 direct，page cache 会让"随机读"变成"内存读"

2. fio 之前 fio --filename=... --rw=write --io_size=400G 预热
   → SSD 没写过的页（trim 状态）读出来很快但是假象

3. 队列深度 iodepth：
   → 单线程 NVMe 测 IOPS 至少 32-128
   → SATA SSD iodepth=32 即可（HBA 队列限制）

4. 多线程 numjobs：
   → 测带宽用 numjobs=多个、bs 大
   → 测 IOPS 用 numjobs=多个、bs=4k

5. runtime 至少 5 分钟
   → SSD 有 SLC cache，开始几秒数字虚高
   → 真实长时持续 IOPS 通常 30-50% 峰值

6. 不要测整盘 100% 容量
   → 写满后 GC 触发，性能崩
   → 留 10-20% OP（over-provisioning）

SPECsfs —— NAS / 文件存储基准

SPEC SFS 2014 / SPECstorage Solution 2020 是 NAS 选型主基准。

1
2
3
4
5
6
7
8
9
4 个 workload pattern：
  SWBUILD     软件构建（小文件密集）
  VDA         视频数据采集（大顺序写）
  EDA         电路设计（混合读写）
  AI_IMAGE    AI 训练数据集（小文件随机读）

指标：
  ops/sec（操作数）
  ORT（Overall Response Time，关键阈值）

NetApp / Pure / IBM / Huawei OceanStor 等存储厂家在 SPEC 官网定期提交结果——是 NAS 招标的硬指标。

IO500 —— 分布式存储榜

IO500 半年度榜单，分布式 / HPC 存储事实尺。

1
2
3
4
5
6
7
8
9
10
11
12
13
工作负载：
  IOR easy / hard：    带宽
  mdtest easy / hard：  元数据
  find：               遍历

子分数：
  Bandwidth + Metadata = IO500 score（GiB/s × kIOPS）

榜单：
  Frontier (ORNL Lustre)：     ~5000 IO500 score
  WekaFS in 多家 site
  GPFS / Spectrum Scale
  Ceph

待补充：2026 年最新 IO500 榜单。

GPU 集群验收里通常会跑 IOR / mdtest 而不是完整 IO500——要的就是带宽和元数据上限。

GPUDirect Storage 基准

GPUDirect Storage (GDS) 让 NVMe 数据直通 GPU 显存，绕开 CPU bounce buffer。

1
2
3
# NVIDIA 自带 gdsio 工具
gdsio -d 0 -D /mnt/wekafs -w 8 -s 1G -i 1024K -I 0 -x 0 -T 60
# -d device, -D dir, -w workers, -s size, -i I/O size, -I direction(read), -T runtime
1
2
3
4
观察：
  GiB/s：           直通带宽
  CPU 利用率：       应该接近 0（成功 bypass）
  HBM 占用：         数据应该出现在 GPU 显存
1
2
传统路径：     SSD → DMA → CPU RAM → PCIe → GPU HBM    （瓶颈：CPU bounce + PCIe 一圈）
GDS：         SSD → DMA → PCIe → GPU HBM             （直接，~3-5× 带宽）

LLM checkpoint / dataloader 用 GDS 显著提升——这就是为什么 WekaFS / DDN / VAST 等 AI 存储厂商都强调 GDS 认证。

网络基准

iperf / iperf3 —— TCP/UDP 吞吐

1
2
3
4
5
6
# 服务端
iperf3 -s

# 客户端
iperf3 -c <server_ip> -t 60 -P 8 -O 5
# -t 60s, -P 8 并发流, -O 5 omit 前 5s 预热
1
2
3
4
观察：
  GBits/sec：    总吞吐
  Retransmits：  重传（网络丢包指标）
  RTT：          基础延迟

qperf / netperf —— 延迟 + 吞吐综合

1
2
3
4
5
# qperf 服务端
qperf

# 客户端
qperf <server> -t 30 tcp_bw tcp_lat

netperf 更老牌，cloud 自己测试常用。

ib_write_bw / ib_read_bw / ib_send_lat —— InfiniBand RDMA

perftest 套件：

1
2
3
4
5
# 服务端
ib_write_bw -d mlx5_0 -F

# 客户端
ib_write_bw -d mlx5_0 -F <server_ip> --report_gbits
1
2
3
4
5
ib_write_bw：    单向 RDMA Write 带宽
ib_read_bw：     单向 RDMA Read 带宽（通常稍低于 Write）
ib_send_bw：     SEND 操作带宽
ib_write_lat：   单向 RDMA Write 延迟
ib_send_lat：    SEND 延迟
1
2
3
4
5
6
7
NDR 400G InfiniBand 单端口 期望：
  ib_write_bw：    ≈ 380-395 Gbit/s（理论 400G 的 ~95%）
  ib_write_lat：   < 1 μs（机内）
  
跨柜（OSFP 光缆 + Quantum-2 交换机）：
  ib_write_bw：    ≈ 360-390 Gbit/s
  ib_write_lat：   ~2-5 μs

低于这个数就要排查 cable / FEC / GPU NUMA / firmware。

NCCL-tests —— 集合通信

GPU 集群验收必跑。NVIDIA SA 视图里：

测试 含义
all_reduce_perf AllReduce 带宽（最关键）
all_gather_perf AllGather
reduce_scatter_perf ReduceScatter
broadcast_perf Broadcast
reduce_perf Reduce
alltoall_perf AllToAll（MoE 关键）
sendrecv_perf Point-to-point

关键指标：

1
2
busbw (bus bandwidth)：考虑算法因子后的"真实"带宽，跨规模可比
algbw (algorithm bandwidth)：原始数据量 / 时间
1
2
3
4
5
6
7
# 单机 8 卡
all_reduce_perf -b 1G -e 16G -f 2 -g 8

# 多机（结合 mpirun + slurm）
mpirun -np 64 -hostfile hosts.txt \
  -x NCCL_DEBUG=INFO -x NCCL_IB_HCA=mlx5_0,mlx5_1 \
  all_reduce_perf -b 1G -e 16G -f 2

常用环境变量：

1
2
3
4
5
NCCL_IB_HCA       指定 HCA
NCCL_TESTS_SPLIT  拆分通信器
NCCL_ALGO         算法（Tree / Ring）
NCCL_PROTO        协议（Simple / LL / LL128）
NCCL_DEBUG=INFO   排障

busbw 期望值（H100 / B200 单机 8 GPU）

1
2
3
4
H100 SXM5 8 GPU AllReduce busbw：    ~370-400 GB/s（NVLink 4 域内）
B200 SXM5 8 GPU AllReduce busbw：    ~700-900 GB/s（NVLink 5 域内）
NVL72 72 GPU AllReduce busbw：       ~700-900 GB/s（NVLink 5，72-domain）
跨节点 8节点 H100 over IB NDR：       ~80-100 GB/s（IB 限制）

低于这个值优先排查：

1
2
3
4
5
1. NVLink 拓扑（nvidia-smi topo -m）
2. PCIe Gen5 x16 是否 lane 全开
3. NCCL_TOPO_FILE / NCCL_GRAPH_FILE 是否被错误使用
4. NUMA binding（mpirun 加 PE=12 / map-by 等）
5. ATS / PCIe ACS 是否关闭

SHARP —— InfiniBand 内 in-network compute

NVIDIA Quantum-2 / Quantum-3 交换机支持 SHARPv3：AllReduce 在交换机内完成，减少 NIC 流量。

1
2
3
4
5
6
7
8
普通 RDMA AllReduce：
  每节点把数据通过 NIC → 交换机 → NIC 给其他节点 → 累加
  N 节点 = N 倍流量
  
SHARP：
  数据进交换机后在芯片内累加，结果广播回去
  N 节点 ≈ 2 倍流量
  → 大规模 AllReduce 性能跃升

跑 NCCL-tests 时打 NCCL_COLLNET_ENABLE=1 启用 SHARP 路径。

一张速查

层级 工具 主指标
块/SSD fio IOPS, BW, P99 lat
文件系统 fio 同上（+ overhead）
NAS SPECstorage SFS 2020 ops/sec, ORT
分布式 IO500 / IOR / mdtest bw + meta
GPUDirect Storage gdsio GiB/s, CPU = 0
TCP/UDP 网络 iperf3 Gbit/s, retrans
RDMA ib_write_bw / perftest Gbit/s, lat
集合通信 nccl-tests algbw / busbw

一些验收脚本骨架

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 节点级（单机）
fio --name=4krand --filename=/dev/nvme0n1 \
    --rw=randread --bs=4k --iodepth=128 --numjobs=8 \
    --runtime=300 --time_based --direct=1 --group_reporting

iperf3 -c $NEIGHBOR -t 60 -P 8

ib_write_bw -d mlx5_0 -F $NEIGHBOR --report_gbits

# 单机 8 卡 collective
all_reduce_perf -b 1G -e 16G -f 2 -g 8

# 多机（slurm）
sbatch nccl_test.slurm    # 内含 mpirun + all_reduce_perf 多 size

小结

  • 存储 benchmark 用 fio 是事实标准，必须 direct=1、足够队列深度、足够时长
  • NAS 看 SPECsfs，分布式存储看 IO500
  • 网络 TCP 用 iperf3，RDMA 用 perftest 套件，集合通信用 nccl-tests
  • ib_write_bw 应跑到端口理论的 ~95%，低于 90% 就要排查
  • NVLink 域内 AllReduce busbw 是 GPU 集群验收最重要数字
  • SHARP 让 InfiniBand 大规模 AllReduce 翻倍快

下一篇讲 AI 基准——MLPerf、cuBLASMatmulBench、nvbandwidth、NeMo 烧机。