从机械盘到持久内存：我的存储性能调优踩坑实录（附fio避坑配置）-开发者社区

从机械盘到持久内存：我的存储性能调优踩坑实录（附fio避坑配置）

第一次用fio测试NVMe SSD时，我盯着屏幕上可怜的300MB/s吞吐量百思不得其解——这块标称3.5GB/s的盘怎么连十分之一性能都跑不出来？直到凌晨三点查看系统日志时，才发现测试目录居然挂载在机械硬盘上。这场闹剧开启了我五年的存储性能调优之旅，从SATA SSD到傲腾再到持久内存，每个新硬件都带来新的性能陷阱。本文将分享那些让我掉光头发的真实案例，以及用鲜血换来的fio黄金配置模板。

1. 存储介质演进与性能特性

2008年我管理的第一个MySQL数据库还在用15K RPM的SAS机械盘，当时最头疼的就是随机IOPS不足200。如今存储介质已经历三代革命：

介质性能对比表

存储类型	延迟(μs)	随机IOPS	顺序吞吐量	典型寿命
机械硬盘(15K)	2000-4000	150-300	200MB/s	5年+
SATA SSD	50-100	50K-100K	550MB/s	3-5年
NVMe SSD	10-20	300K-1M	3-7GB/s	3年
傲腾SSD	5-10	500K-2.5M	2-6GB/s	5年+
持久内存(PMem)	0.1-0.3	10M+	15GB/s+	10年+

这个演进过程中有三个关键转折点：

接口瓶颈突破：从SATA 6Gbps到PCIe 3.0 x4的32Gbps，NVMe协议将队列深度从SATA的32提升到64K
介质革命：NAND闪存到3D XPoint，持久内存的字节寻址特性彻底改变了存储栈
软件适配：传统文件系统为块设备设计，需要DAX、libpmem等新机制适配新硬件

提示：测试前务必用lsblk -d -o name,rota确认设备类型，我见过太多把NVMe测成SATA的悲剧

2. fio测试中的七个致命陷阱

2.1 队列深度与线程数的黄金组合

第一次测试企业级NVMe时，即使把iodepth调到256也才跑到标称性能的30%。后来发现需要配合numjobs才能打满并行度：

# NVMe SSD最佳实践配置 [global] ioengine=libaio direct=1 runtime=60 time_based group_reporting [randread] bs=4k rw=randread iodepth=32 numjobs=8 # 总队列深度=iodepth*numjobs=256

不同介质的队列深度建议

机械硬盘：iodepth=1（高了反而降低性能）
SATA SSD：iodepth=4-16
NVMe SSD：iodepth=32-256
持久内存：iodepth=4 + numjobs=32（需绑定CPU核）

2.2 块大小(block size)的魔术效应

测试PMem时用4K块大小得到200万IOPS沾沾自喜，直到发现官方文档用256B测出1000万IOPS。不同场景的推荐配置：

数据库：4K-16K（匹配页大小）
视频处理：1M+（大文件顺序读写）
日志系统：512B-4K（小文件随机写）

2.3 混合读写测试的坑

测试70%读30%写的混合负载时，这个配置让我栽了跟头：

rw=randrw rwmixread=70 # 实际需要配合rwmixcycle参数

后来发现需要在不同比例下稳定运行足够时长才能得到准确结果，建议每个比例单独测试。

3. 持久内存的特殊调优技巧

3.1 DAX挂载的必要性

第一次测试Intel Optane PMem时性能不如普通NVMe，排查发现漏了关键步骤：

# 错误做法（性能损失50%+） mkfs.xfs /dev/pmem0 mount /dev/pmem0 /mnt/pmem # 正确做法 mkfs.xfs -f -d su=2m,sw=1 /dev/pmem0 mount -o dax /dev/pmem0 /mnt/pmem

DAX(Direct Access)模式绕过页缓存，直接映射到应用地址空间，延迟降低10倍。

3.2 libpmem引擎的秘密

使用传统ioengine测试PMem就像用牛车测F1赛道：

[pmem_test] ioengine=libpmem # 而不是libaio direct=1 size=100G filename=/mnt/pmem/testfile [4k_randwrite] bs=4k rw=randwrite iodepth=4 numjobs=32 cpus_allowed=0-15 # 必须绑定CPU

3.3 内存模式 vs 应用直接模式

PMem有两种使用方式，性能差异惊人：

内存模式：作为易失性内存使用，延迟100ns级
应用直接模式：持久化使用，需处理刷写问题

实测发现直接使用pmemkv等优化库比裸设备性能高40%

4. 全链路性能剖析方法论

4.1 观测工具三件套

当fio结果异常时，我的诊断流程：

iostat -xmt 1：看%util和await
- 机械盘util高是瓶颈，NVMe util高可能正常

blktrace定位IO路径耗时：

blktrace -d /dev/nvme0n1 -w 60 blkparse -i nvme0n1 -d nvme.blktrace.bin btt -i nvme.blktrace.bin

perf trace看系统调用：

perf trace -e syscalls:sys_enter_io_submit

4.2 文件系统的影响测试

在EXT4/XFS/Btrfs/NOVA上的fio性能对比（4K随机写）：

文件系统	IOPS	延迟(μs)	CPU利用率
EXT4	150K	85	35%
XFS	180K	70	28%
NOVA	250K	45	15%

4.3 电源管理陷阱

某次深夜测试发现性能波动严重，最终发现是BIOS的节能设置：

# 禁用CPU节能 cpupower frequency-set -g performance # 禁用PCIe ASPM echo "performance" > /sys/module/pcie_aspm/parameters/policy

5. 实战配置模板库

5.1 NVMe SSD全维度测试

[global] ioengine=libaio direct=1 runtime=300 ramp_time=10 time_based group_reporting filename=/mnt/nvme/testfile # 带宽测试 [seqread] bs=1M rw=read iodepth=32 numjobs=4 # 延迟测试 [latency] bs=4k rw=randread iodepth=1 numjobs=1

5.2 持久内存混合负载模板

[pmem_mix] ioengine=libpmem direct=1 size=200G filename=/mnt/pmem/testfile [70read_30write] bs=256B rw=randrw rwmixread=70 iodepth=4 numjobs=16 cpus_allowed=0-15