1 问题背景

虚拟机（8C16G）裸盘（预分配80G）fio 4k随机写测试（4jobs，iodepth为32）TaiShan 200服务器性能不符合预期，需要进行调优。

2 原因分析

1. 执行测试命令，观察TaiShan服务器表现：物理机上，发现kvm进程cpu占用较高，进一步分析发现TaiShan上kvm线程200+；虚拟机上，TaiShan cpu0占用率很高，其中软中断占比高的不合理。怀疑是虚拟机实现方式的问题，发现TaiShan虚拟机测试磁盘类型为virtio-scsi-device（可以使用virtio-block-device，block设备比scsi设备IO路径稍微短些），且当前测试使用的qemu版本较低，可能还不支持armv8新特性。
2. 修改TaiShan虚拟机启动参数，将测试盘类型调整为virtio-block-device，性能有小幅提升，物理机上kvm线程数从200+降低到80以内，虚拟机上cpu0的软中断也较低到合理范围，但系统占用又变得很高，说明kvm线程和软中断高是磁盘类型导致，此时是cpu瓶颈。无法给TaiShan虚拟机指定cpu asimd特性，显示参数错误。
3. 将虚拟机vcpu一对一绑核，关闭irqbalance,给fio测试程序绑核，几乎没有性能提升。开启大页内存，没有性能提升。
4. 分析fio系统调用，发现clock_gettime系统调用耗时有时达到2ms，耗时很高，此客户机操作系统为3，更换为centos7.7，fio系统调用看不到clock_gettime函数，但是性能没有提升。
5. 使用原生0.0版本测试，性能有一定提升;进一步重新编译qemu，加上对native aio的支持，性能提升较大。此时，虚拟机上仍然是cpu0 占用特别高，物理机上观测一个vcpu线程cpu占用特别高，qemu主线程cpu占用不高。
6. 尝试给磁盘配置iothread卸载qemu主线程压力、对磁盘添加write-cache=on和ioeventfd =on等属性、排查TaiShan物理机上对应SSD的性能表现，没有性能提升。将物理机上SSD的调度策略由默认的cfq调整为noop，性能有一定提升。
7. 使用7开始对virtio-blk支持的新特性multiqueues磁盘多队列，性能有较大提升，虚拟机上单个cpu占用特别高的问题解决了。
8. 进一步优化，将TaiShan iommu模式配置为passthrough，性能有进一步提升。

3 解决方案

1. 使用新版qemu如0.0或更高版本,guest os版本也尽量高点
2. 使用virtio-blk磁盘多队列特性
3. 虚拟机异步io模式配置为native
4. 若虚拟化场景无需使用磁盘、网卡直通或SRIOV特性，则可关闭SMMU。

4 总结

虚拟化场景IO测试，IO路径较长，且不同类型磁盘IO路径也不同。首先需要确认磁盘bus类型（scsi、ide、virtio），保证使用的磁盘文件的协议（nfs、iscsi、本地挂载）是一致的,保证磁盘文件在对应物理机上创建的规则是一样的（预分配、缓存特性等）。如果判断是单核瓶颈，可以尝试使用磁盘多队列特性（针对virtio-blk设备，对qemu、geust操作系统版本有要求）；如果是qemu主线程占用高，可以考虑开启iothread分担压力（可能影响动态迁移特性，需调研）；设置磁盘异步调用为native会有性能提升，不过也有一定的使用限制（不能用于sparse images，否则在文件系统元数据需要更新时会导致qemu threads阻塞），需了解使用需求。

实际测试中，瓶颈分析需要结合虚拟机和物理机两者的系统表现，因为虚拟机的cpu、io等占用信息不一定是真实的（存在vcpu等kvm线程本身被调度和阻塞的问题等）。