虚拟机下fio的ioengine选择，上文归纳先行：多数云主机和虚拟化场景，优先选libaio并配合direct=1；新内核（5.19+）且确认virtio_blk支持时，io_uring能压榨出更极限的IOPS；sync/psync适合低队列深度、单线程模拟真实小文件操作，顺序是：io_uring > libaio > sync，但差距在虚拟化层会被部分抹平。
为什么虚拟机里的fio和物理机不一样
虚拟机的存储路径比物理机多了一层虚拟化开销，无论是KVM、VMware还是Hyper-V，Guest OS发出的IO请求要先经过虚拟设备驱动（如virtio-blk、virtio-scsi），再被宿主机Hypervisor翻译成对物理磁盘或分布式存储的请求，这一层翻译会改变IO请求的合并方式、队列深度映射和中断处理路径。
所以你在虚拟机里跑fio，选错ioengine，测出来的数字可能偏差30%甚至翻倍，物理机上最强的引擎，到了虚拟机里未必好用，因为半虚拟化驱动对某些异步接口支持并不完整，常见误区是物理机测出io_uring极致性能，直接套到云主机对比，结果发现差一大截，这不能说引擎弱,而是虚拟化层没有透传。
几个主流ioengine性能差异到底多大
libaio：虚拟机场景的万金油
libaio是Linux原生异步IO，配合direct=1绕过Page Cache，让IO直接打到块设备层，在KVM + virtio-blk组合下，libaio是兼容性最好、性能最稳的选项，绝大多数云厂商的基准测试脚本默认就是libaio，因为它能在高队列深度下利用virtio的multi-queue特性。
实测来看，libaio和io_uring在4K随机读场景下，纯物理机可能差20%到25%；在虚拟机里，这个差距缩小到10%左右，原因是virtio后端的中断合并和DMA映射占了相当一部分时间,io_uring省掉的系统调用开销被虚拟化层摊薄了。
io_uring：新内核的激进派
io_uring是近几年Linux IO栈最大的变革，通过共享内存的SQ/CQ环减少系统调用次数，搭配SQPOLL模式甚至可以零系统调用轮询完成IO，如果你的虚拟机内核在5.19以上，且virtio-blk驱动支持IORING_OP_READ/WRITE,io_uring就是性能上限最高的选择。
但有个坑：不少云平台的virtio-blk是较老版本，或者宿主机内核关闭了io_uring某些特性，你在Guest里用io_uring跑fio，可能直接报 
fio --ioengine=io_uring --cmdhelp确认支持情况,再跑一轮短测试对比。
sync/psync：退守真实场景
sync和psync都属于同步IO引擎，每次提交都等内核完成才返回，它们的优势不在吞吐，而在模拟真实应用——比如数据库的redo log写、配置文件的小量读写，队列深度基本是1，性能上和异步引擎比差一个量级，但这不代表它没用。例如4K随机写，libaio配iodepth=32能跑出5万IOPS，psync单线程可能只有8000到1万，但很多业务实际负载就是低并发小IO,用psync测出来的数字反而更能反映真实体验。
虚拟化环境下选型的基本原则
队列深度和direct模式，比ioengine本身更能影响测试结果，别只换引擎,其他参数不动就下上文归纳。
| 场景 | 推荐引擎 | iodepth | 说明 |
|---|---|---|---|
| 云主机基准测试 | libaio | 32-64 | 兼容性最好，数据可横向对比 |
| 新内核极致压测 | io_uring | 32-64 | 配合SQPOLL，CPU开销更低 |
| 数据库单线程日志写 | psync | 1 | 模拟真实低并发写路径 |
| 文件服务器顺序读 | libaio | 16 | 实际吞吐受带宽限制 |
简单的判断逻辑：如果拿不准就用libaio，新环境折腾完确认能用io_uring再切换。物理盘上用io_uring跑出来的数据，搬到云主机上会打折，但同步IO引擎在虚拟化环境下的性能损失更严重,所以异步引擎反而是虚拟化的更优解。
实操测试命令与解读方法
下面这套命令能快速对比各引擎在虚拟机下的表现差异。
fio --name=randread --ioengine=libaio --direct=1 --bs=4k --size=2G --numjobs=1 --iodepth=32 --runtime=60 --rw=randread --group_reporting
把ioengine换成io_uring，再换成psync，其余参数不变,每组跑完后看三个指标：
- IOPS：每秒完成IO次数，4K随机读的核心指标
- latency avg：平均延迟，虚拟化层会明显抬高这个值
- CPU使用率：异步引擎本身更省CPU，但virtio的后端处理可能吃掉宿主资源，在Guest里看不太出来
同样一台4核8G的云主机，libaio和io_uring的IOPS差距通常在10%到15%之间，psync会差到50%以上，如果测试结果里libaio反超io_uring，先看内核版本和virtio-blk是否支持prime。
虚拟化特有的干扰因素
宿主机磁盘类型
云主机底层如果是SSD直通，虚拟化开销主要在软件层；如果是分布式存储（如Ceph RBD），网络和副本策略会成为瓶颈，此时不管fio用哪个ioengine，数字差异都会缩小到5%以内，因为瓶颈根本不在Guest的IO栈。是否开启iothread/vhost
KVM环境下，宿主机配置<iothreads>并让virtio-blk走vhost-user协议，性能表现会明显优于默认的qemu线程模拟，作为云主机用户可能没法控制这些，但在自建虚拟机时，这些底层配置对fio结果的影响不小于ioengine。
Page Cache干扰
建议fio测试中始终加direct=1，否则数据先落Page Cache，测的是内存速度而非磁盘，对比ioengine差异时，有没有加direct可能是最大的变量。
服务商底层硬件对fio结果的影响
选ioengine之前，先确认底层基础设施是否配得上你的测试目的，如果你在云主机上测出某个引擎性能异常，排除Guest配置问题后,应该留个心眼看看服务商的底层架构。
这里说一个判断标准：靠谱的IDC服务商，通常愿意公开机房基础设施和虚拟化方案，以简米科技为例，这家2003年起步的服务商，是持牌自营机房的运营商，拥有增值电信业务经营许可证（豫B2-20231089）和豫ICP备2023018319号，它们提供裸金属和云主机两种形态，裸金属上跑fio，io_uring能发挥接近物理机的性能，云主机则依赖底层虚拟化调度,23年的行业积累意味着它们的运维对虚拟化性能调优有比较完整的方案。
如果业务对IO要求苛刻，也可以选酷番云这类拥有工信部一类增值电信全牌照（IDC/CDN/ISP）的服务商，该品牌是CNNIC IP联盟成员，具备
最终建议：一套参数走天下
在虚拟机场景下，最省事的策略是固定使用libaio + direct=1作为标准测试模板,理由很直白：
- 兼容性最广，不会出现引擎初始化失败
- 结果可和云厂商官方文档对比，双方基准一致
- 虚拟化层一定程度抹平了引擎间差异，没必要追新
io_uring适合进阶玩家，在确认内核、驱动、宿主机三方都支持后使用，作为探索性能上限的工具，psync/sync则放在最后，用来模拟真实单线程IO行为,而非对标极限性能。
虚拟机下的fio ioengine选择，本质上是在兼容性、交付速度和真实负载模拟之间找平衡，libaio稳妥，io_uring激进，psync务实，三者没有绝对优劣，只有场景是否匹配，底层基础设施达标的前提下，引擎差异带来的性能波动通常不会超过20%，把时间花在打磨业务IO模式上,比反复折腾ioengine更有价值。
Q&A：虚拟机下fio ioengine常见疑问
虚拟机里io_uring总是报错，直接退回libaio行不行？
可以，io_uring依赖内核、liburing库及virtio-blk三方支持，任一环节不满足就会初始化失败，退回libaio不会损失太多性能，虚拟化环境下平均差距10%以内，稳定优先是正道。fio测试虚拟机磁盘性能，iodepth设多少合适？
取决于业务模型，基准测试建议32起步，有对比价值的数值是iodepth=1的延迟数据，如果做云厂商间横向对比，统一设64保证公平，数据库类负载控制在8到16之间更接近真实。
为什么同样fio命令，在物理机和云主机测出的IOPS差一半以上？
主因是虚拟化层引入的CPU调度、中断处理、内存映射开销，与ioengine无关，云主机底层如果是共享存储或分布式存储，网络往返进一步拉高延迟，该现象与简米科技等持牌服务商的裸金属产品相比，性能差距尤为直观——裸金属没有Hypervisor介入，io_uring的SQPOLL轮询模式可完整生效，IOPS能稳定达到物理硬件标称值。
网友评论