这是nmon工具的屏幕截图,显示了随着时间推移的cpu性能和当前的存储吞吐量.他们展示的是典型的：
通过使用打包工具使用qemu构建Debian和Ubuntu映像,我在其他两台机器上复制了相同的性能问题.这是我的qemu命令行：
/usr/bin/qemu-system-x86_64 -netdev user,id=user.0,hostfwd=tcp::3213-:22 -device virtio-net,netdev=user.0 -cdrom /home/$user/packer_cache/23e6874116128e16e11cfad1c369c54be97c20023e59b9b9d39d312233e09cd6.iso -m 512M -display sdl -machine type=pc,accel=kvm -vnc 0.0.0.0:47 -name packer-openstack -drive file=output-openstack/packer-openstack.qcow2,if=virtio,cache=none -boot once=d
如您所见,我正在使用virtio驱动程序,而cache = none.
我甚至修补了packer在qemu-img create的参数中使用-o preallocation = Metadata.这似乎略微改善了一些事情,但性能仍然比主机系统低几个数量级.
这个特定的屏幕截图是在Ubuntu安装的“安装基本系统”阶段拍摄的,但它与或多或少的任何存储使用一致.
它是在我的工作站上拍摄的,这是一台带有SSD的Macbrook Pro;具有相同问题的Openstack机器正在运行RAID10集群,我在主机系统上以大约1200MB / s的速度进行基准测试.
显然,我不认为qemu下的存储性能与主机系统的存储性能相匹配 – 但它的速度有多慢. Openstack集群上的主机虚拟机需要几秒钟来执行操作,就像postgres中的CREATE DATABASE语句一样简单.
目前我留下的唯一线索就是这里的截图：
这里nmon显示/ dev / sda具有完全利用率,但/ dev / sda7–实际拥有qcow2映像的分区 – 只有1％的使用率.后一个统计数据与我实际期望的磁盘性能相匹配.
值得注意的是,这里的饱和度并不仅仅是我的监控工具的一个工件：在发生这种情况时,主机上的所有操作都非常慢.
如何找出实际发生的情况？
我应该看看在主机上使用电梯= noop和客人调整调度程序等内容吗？
–
编辑：这是我工作站上uname -a的输出：
Linux $hostname 3.18.6-1-ARCH #1 SMP PREEMPT Sat Feb 7 08:44:05 CET 2015 x86_64 GNU/Linux
在Openstack机器上：
Linux $hostname 3.13.0-40-generic #69-Ubuntu SMP Thu Nov 13 17:53:56 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
解决方法
您可以尝试：
1)使用cache = writeback(这是一个更安全的选择,“不安全”选项)
2)通过发出“fallocate< filename>< filesize>”来预分配整个qcow2文件在qcow2文件？
显然,只在测试VM上执行上述操作！如果在测试之后一切正常,则可以将更改传播到其他VM.
