使用FIO基准测试PMEM时，带宽取决于哪些参数？

Great question—let’s break down exactly what’s driving the sequential read bandwidth you’re seeing with your FIO test on PMEM, using your command as a reference:

fio --name=readf --filename=/dev/pmem --iodepth=4 --ioengine=libaio --direct=1 --buffered=0 --groupreporting --timebased --bs=64k --size=10g --rw=read --norandommap --refillbuffers=1 --randrepeat=0 --runtime=300

FIO配置参数 #

这些命令里的设置直接影响带宽表现：

• 块大小 (--bs=64k): 顺序读带宽和块大小高度相关。更大的块能减少单个IO请求的开销，更充分地利用PMEM的高带宽潜力。你用的64k是合理的起点，但测试更大的块（比如256k或1M）通常能拿到更高带宽——只要块大小和PMEM内部的页/块布局对齐就行。
• 队列深度 (--iodepth=4): 因为你用的是libaio异步IO，队列深度控制着同时处于pending状态的IO请求数量。PMEM延迟极低，像4这样的浅队列深度可能不足以 saturate 它的带宽。可以尝试把这个值调到16、32甚至64（要确保系统的aio-max-nr内核参数足够高以支持）。
• IO引擎 (--ioengine=libaio): 虽然libaio能用于块设备，但它并不是为PMEM优化的。FIO有专门的pmem IO引擎，可以绕过内核VFS层直接访问PMEM，消除不必要的开销。换成--ioengine=pmem几乎肯定能提升你测得的带宽。
• 直接IO (--direct=1): 你这个设置是对的——禁用页缓存确保你测得的是PMEM的原始性能，而不是DRAM的缓存读。这对PMEM基准测试来说至关重要。
• 测试数据量与时长 (--size=10g, --runtime=300): 要得到稳定、有代表性的带宽数值，得确保测试不会只从DRAM缓存读（即使开了直接IO，也可能存在一些底层缓存）。你设置的10G数据量和5分钟运行时长很扎实，但如果你的PMEM设备大得多，可以考虑增大--size，避免过于频繁地重复读取同一区块。
• 顺序性保障 (--norandommap): 这个参数确保FIO严格按顺序读取，这是最大化顺序带宽的关键。如果禁用它，测试就变成随机读了，带宽会大幅下降（PMEM在顺序吞吐量上表现突出）。

PMEM硬件与系统层面因素 #

除了FIO设置，这些外部因素也起到了关键作用：

• PMEM型号与代际: 不同的PMEM硬件有不同的带宽上限。比如Intel Optane DC PMEM 200系列每根DIMM能提供~3 GB/s的带宽，而300系列能接近4 GB/s每根DIMM。基于DDR5的PMEM模块带宽会更高。
• PMEM部署模式: 你用的是App Direct模式（通过/dev/pmem），这对块设备工作负载来说很理想。内存模式（PMEM作为扩展DRAM）的带宽会略高，但不适用于你这种把它当块设备的场景。
• DAX（直接访问）配置: 确保你的/dev/pmem设备开启了DAX。DAX允许应用直接访问PMEM，无需把数据拷贝到DRAM，能大幅节省带宽开销。如果没开DAX，会出现不必要的数据拷贝，降低吞吐量。
• 系统内存通道利用率: PMEM和DRAM共享内存通道。如果系统的所有内存通道都被DRAM占用，PMEM的带宽会受到限制。为了最大化吞吐量，要在可用通道间平衡DRAM和PMEM的配置。
• 系统负载: 系统上任何并发的CPU、内存或存储工作负载都会抢走FIO测试的带宽。一定要在空闲系统上运行基准测试，才能得到准确结果。

针对你测试的快速优化建议 #

1. 切换到PMEM优化的IO引擎：--ioengine=pmem
2. 把队列深度调到16或32：--iodepth=16
3. 测试更大的块大小：--bs=256k 或 --bs=1M
4. 验证/dev/pmem是否开启了DAX（用ndctl list -NR检查）

内容的提问来源于stack exchange，提问作者Pushpe