并行文件系统性能基准与调优：IOR/mdtest 实测方法

实验目标

Lustre、BeeGFS、GPFS 装好挂上之后，"读写挺快"不算数——训练集群对存储的要求是可量化、可复现、可回归的：

• 部署验收时，用什么基准证明这套存储满足设计指标（如"每节点 2GB/s 读、10 万 IOPS 元数据"）？
• 训练跑起来后性能下降，怎么区分是存储层、网络层还是应用层的问题？
• 每次扩容/调参后，如何用同一套方法确认没有变差？

本篇以 IOR 与 mdtest 为主线，逐段拆解并行文件系统性能基准的实测方法：参数语义、工作负载建模、结果判定与调优路径。命令为真实可复现操作；具体数字随硬件与环境而异，方法描述不编造基准。

第一段：理解两个基准的分工

工具	测什么	对应训练负载
IOR	数据带宽（读/写，块大小与并发可控）	训练数据加载、checkpoint 写入、推理缓存
mdtest	元数据操作速率（create/stat/delete，文件数可控）	海量小文件：数据集清单扫描、断点续训目录遍历

两者缺一不可：带宽高但元数据慢，是"大文件爽、小文件卡"的典型；反过来则是"文件操作快但数据流不够"。

第二段：IOR 实测——命令与参数逐段拆解

# 基础带宽测试：64 进程 × 16GB 块，写入 1GiB 文件（可调）
mpirun -np 64 -hostfile hosts.txt \
  /usr/local/bin/ior -a POSIX -o /mnt/pfs/ior-test.dat \
  -w -r -b 1g -t 16m -F -e -g \
  -i 1

参数语义：

参数	含义	调整要点
-w -r	先写后读	同时测读写带宽
-b 1g	每进程文件大小 1GiB	总数据量 = 进程数 × 块大小，要覆盖真实训练集规模
-t 16m	传输块 16MiB	模拟大块连续读写（训练数据/checkpoint）；小块（如 4k）测随机小 IO
-F	每进程独立文件	模拟多进程并发写不同文件（checkpoint 分片）；去掉 -F 测共享文件
-e	带 fsync	模拟"必须落盘"场景，不加则测纯缓存吞吐
-g	测试间隙	避免并发干扰

判定方法：

• 记录 Aggregate write/read bandwidth 与 IOPS（IOR 输出中直接给出）；
• 对照部署前的设计指标（由硬件规划推导）与厂商参考值；
• 关键是做回归基线：首次验收跑一遍存下结果，此后每次扩容/调参用同一命令复跑对比——没有基线的基准没有意义。

第三段：mdtest 实测——元数据速率

# 元数据测试：64 进程，每进程创建 1 万个文件（目录可调）
mpirun -np 64 -hostfile hosts.txt \
  /usr/local/bin/mdtest -d /mnt/pfs/mdtest-dir \
  -n 10000 -i 3 \
  -C -T -r

• -C（create）、-T（stat）、-r（remove）分别测三类元数据操作；
• 关注 files/s（每秒文件操作数），这是训练数据清单扫描、checkpoint 元数据更新的直接指标；
• 目录数的影响：单目录 1 万文件 vs 每进程独立目录，结果差异巨大——按真实数据布局（数据集一般分目录组织）建模，而不是都压在一个目录里。

第四段：工作负载建模——基准要"像训练"

生搬 IOR 默认参数测出来的数字，往往和训练体验对不上。建模原则：

1. checkpoint 场景：大块写 + 落盘（-e），多进程共享一个文件或分片文件，块大小按模型权重分片（如 2-8MB）——对应 11 章 checkpoint 写入路径；
2. 数据加载场景：顺序大块读（-t 1m~16m），读吞吐是训练数据供给的直接约束；
3. 小文件场景：数据集由大量小文件组成时（如图像、日志、科学数据），mdtest 的 create/stat 速率才是真实瓶颈，同时用 -t 4k 的 IOR 测随机小 IO；
4. 并发规模：进程数对齐真实训练并发（如 512 卡训练时存储基准至少用 128-256 进程），单进程测出来的"很高"不代表集群场景。

工程观察：性能问题的第一判断不是"存储慢"，而是"用哪个指标判断慢"。训练慢先看是数据加载（读带宽/小文件）还是 checkpoint（写+落盘）环节，再选对应基准复测——基准选错了，排查方向就错了。

第五段：常见瓶颈与调优路径

现象	定位	调优方向
大块读吞吐不足	IOR -t 16m 读低于设计值	客户端并发、网络（RDMA）、服务端条带宽度与块大小
小文件/元数据慢	mdtest create/stat 速率低	元数据服务器/目标数、目录分片、聚合目录策略
写满后性能骤降	检查点写 + -e 后带宽塌陷	写缓存策略、条带数、OST/MGT 负载均衡、存储介质分层（NVMe 写缓存）
客户端偶发卡顿	单点延迟抖动（IOR 看 P 值分布）	网络 QoS、客户端挂载参数（如 lustre lazystatfs）、服务端 CPU 中断绑定

注意：调优动作要一次只改一个变量，改完立即用同一命令复跑对比——并行文件系统变量耦合强（条带 × 客户端数 × 网络），混合改动无法归因。

基准检查清单

• [ ] 基准命令参数对齐真实负载（checkpoint/数据加载/小文件分别建模）
• [ ] 并发进程数覆盖集群真实规模（至少 1/4 训练并发）
• [ ] 首次验收跑完存下基线结果（带宽/IOPS/元数据速率 + 命令全文）
• [ ] 每次扩容/调参用同一命令复跑，结果与基线对比
• [ ] 性能下降时按"数据加载 vs checkpoint"选对应基准复测定位
• [ ] 调优一次一个变量，改后立即复测

工程启示

• 基准是"标尺"，不是"成绩单"：给存储设标尺（设计指标 + 验收基线），扩容和调参才有依据，故障排查才有参照。
• 负载建模决定基准价值：测不出训练痛点（checkpoint 落盘、小文件扫描）的基准，数字再好看也是装饰。
• 可复现 > 峰值：同一命令、同一环境、同一基线，才有可比性；临时拼参数测出来的峰值没有长期价值。

下一篇预告：存储吞吐与元数据达标后，预训练集群开始大规模训练——下一篇《MoE 训练工程：专家并行与负载均衡实战》聚焦 MoE 模型在集群上的工程化训练挑战。