fio测nfs/azure文件共享顺序读吞吐量需绕过page cache（direct=1）、用libaio+高iodepth（≥64）、bs=1m，并调高read_ahead_kb至15 mib（linux 5.4+默认128 kib致性能骤降），否则结果虚高2–3倍。
用 fio 测试 NFS/Azure 文件共享的顺序读吞吐量
直接测挂载点路径即可，但必须绕过 page cache、禁用文件系统缓存，并确保测试块大小和队列深度匹配实际负载。默认参数下测出的数值可能虚高 2–3 倍，尤其在 NFS 共享上。
-
direct=1必须开启：否则fio会走内核 page cache，测的是内存带宽而非存储真实吞吐 -
ioengine=libaio推荐搭配iodepth=64或更高：NFS 客户端依赖异步 I/O 并发来摊平网络 RTT，psync引擎在顺序读场景下吞吐常低 40% 以上 -
bs=1M是较稳妥的起点：太小（如 4K）会放大网络协议开销；太大（如 4M）可能触发客户端预读失效或服务端限流 - 测试文件需提前生成且大于内存：避免
fio边写边读导致结果混杂，建议用fio -rw=write -bs=1M -size=5G -name=prep预热一次
Linux 5.4+ 内核下 NFS 顺序读性能掉坑的关键点
不是 fio 参数问题，而是内核预读机制变更导致的隐性瓶颈：5.4 起 read_ahead_kb 默认从「rsize × 15」退化为固定 128 KiB，对大文件顺序读吞吐影响显著。
- 检查当前值：
cat /proc/sys/vm/read_ahead_kb—— 若是 128，基本可判定顺序读 BW 上不去 - 临时调高：
echo 15728640 > /proc/sys/vm/read_ahead_kb（即 15 MiB） - 永久生效需加 udev 规则或写入
/etc/sysctl.conf：添加vm.read_ahead_kb = 15728640 - 该设置仅对顺序读有效，随机读不受影响；Azure 文件共享实测中，此项调整可将
read吞吐从 60 MiB/s 提升至 180+ MiB/s
验证是否真卡在网络或服务端，而不是本地配置
仅靠 fio 输出无法定位瓶颈层级，需交叉验证三个信号源。
- 跑
fio同时执行iostat -dxm 1：若%util很低（await 却高达 50ms+，说明延迟来自网络或远端存储，不是本地磁盘 - 用
sockperf ping-pong -i [server_ip] --time 30测端到端 RTT：Azure 同区部署下应 ≤ 1ms；若 >3ms，先查路由或 NIC 队列 - 观察
/proc/mounts中 NFS 挂载选项：确认含rsize=1048576（即 1M），且不含soft（软挂载会因超时重试拉低吞吐）
为什么不用 dd 测顺序读吞吐
dd 的单线程同步读 + 默认缓冲区（通常 512B–4K）完全无法压满 NFS 管道，测出来只是协议栈最低通路能力，不具备参考价值。
-
dd if=/mnt/nfs/testfile of=/dev/null bs=1M count=1000实测吞吐常只有fio的 1/5～1/3 -
dd不支持iodepth，无法模拟多请求并行，更无法暴露 NFS 客户端连接数不足的问题 - 它不输出延迟分布，遇到偶发丢包或服务端限速时，只会表现为整体速率抖动，无法归因
真正要压测 NFS 共享的顺序读上限，fio 是唯一能同时控制队列深度、I/O 引擎、缓存策略和预读行为的工具。其它方法要么太浅，要么掩盖了关键瓶颈点。
