技术分享：虚拟化环境下解析WindowsIO性能

随着云计算技术与服务的发展和进步，越来越多的客户选择将业务部署到云端。但由于引入了虚拟化层，在业务部署过程中经常会遇到IO问题，通常也不易调试。本文主要介绍利用perf、systemtap等工具，帮助一位托管云客户调试IO性能问题，来分析虚拟环境下Windows IO的性能。

目前创新互联已为数千家的企业提供了网站建设、域名、虚拟空间、网站改版维护、企业网站设计、台江网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。

问题出现

有一次，托管云客户自己搭建了虚拟化环境，在同一台宿主机上创建windows 2008 R2 和 Centos6.5虚拟机，用fio分别测试其随机读性能，windows 2008 R2的IOPS大约在18K，而Linux的IOPS却可以达到100K左右。

客户测试用的fio 配置

 
 
 
 

  
  
  
  
[global] 
  
  
  
  
ioengine=windowsaio 
  
  
  
  
direct=1 
  
  
  
  
iodepth=64 
  
  
  
  
thread=1 
  
  
  
  
size=20g 
  
  
  
  
numjobs=1 
  
  
  
  
[4k] 
  
  
  
  
bs=4k 
  
  
  
  
filename=d:test.img 
  
  
  
  
rw=randread 
 
 
 
 

测试结果

 
 
 
 

  
  
  
  
win_fio1 
 
 
 
 

云主机IO栈

io stack

云主机环境下，整个IO栈相对较长，涉及到Guest OS中的应用层/文件系统/Block层以及驱动层，虚拟化层，宿主机OS文件系统/Block层以及驱动层。因为涉及面多，所以其中任何一个环节出现问题都会造成性能下降，也为做IO的Tracing增加了难度。

从这次得到的信息来看，首先排除了宿主机文件系统和Block层以及驱动层的问题，因为同样情况的配置，Linux系统并没有问题。

目前主要集中于两点：

• Guest OS(Windows系统)
• fio程序
• 文件系统/Block layer
• VirtIO Block驱动

虚拟机为Guest OS提供的是Virtio Block设备：

• QEMU

如何排除QEMU的嫌疑?对于IOPS的性能问题，很容易想到两种可能性:

• IO延时过高
• 设备支持IO队列太短

在队列的问题方面，Linux和Windows虚拟机对应的Virtio Block设备都是一样的，那么就需要确认延时问题。

QEMU 完成Block IO花了多长时间?

幸运的是，Stefan Hajnoczi已经为QEMU添加了Tracing的特性，因此可以很方便的统计出QEMU从接收到一个IO请求到完成所用的具体时长。

从上述统计来看，平均IO完成时间在130us，由此暂时排除QEMU 层造成太高延时的影响。另外，如果关注这种动态Tracing的overhead，从测试观察上大致接近20%。

排除队列和延时问题，可能造成影响的也只有Guest OS了。

• VirtIO Block驱动的问题?至少更新到***稳定版本的Virtio-Win驱动，仍然存在同样的问题。
• Windows 文件系统/Block层的问题?原生Windows系统在确认后并没有做任何配置上的修改。
• fio测试程序的问题？为什么Linux上fio没有问题呢。

两种可能性

在性能排查过程中，总是很容易陷入死局，经常会问到底是哪儿出了问题?因此一切可能影响的因素似乎都没有做任何变动。从经验来看，大部分性能问题都可以分成两种可能:

• on cpu
• off cpu

重新来看这个问题 ，在基本排除IO延时问题后，对应的问题还有两种可能性：

• CPU极其忙碌，但是大部分时间并不是在做IO处理;
• CPU经常处于空闲状态，那相应的也没有主要在处理IO。

注：之所以说到目前为止并不能排除IO延时的影响，是因为只排除了QEMU Block层可能的影响，但是还有Guest OS(这次暂时忽略Guest OS)。

先看测试过程中，虚拟机的CPU消耗情况。

 
 
 
 

  
  
  
  
top -H -p 36256 
 
 
 
 

 
 
 
 

  
  
  
  
win_fio1 
 
 
 
 

从上图来看，QEMU主线程的cpu负载已经达到90%以上，似乎符合on cpu类问题。通常来说，解决这类问题***的办法就是用perf进程采样，然后生成火焰图，因为首先查看CPU具体消耗在什么地方是一个不错的选择。

 
 
 
 

  
  
  
  
perf record -a -g -p 36256 sleep 20 
 
 
 
 

生成火焰图：

 
 
 
 

  
  
  
  
win2008-bad 
 
 
 
 

可以清楚的看到，cpu大部分消耗都是KVM的操作，其中最主要的消耗是vmx_handle_exit。(真实的火焰图是一个矢量图，用浏览器查看很容易确认)。这里引起vmx_handle_exit主要有两点:

• 访问IO Port(handle_pio)
• 访问 MMIO(handle_apic_access)

既然KVM模块占了大部分，那就更希望了解测试时KVM的真实行为，通过另一个工具(kvm_stat)可以达到。

 
 
 
 

  
  
  
  
kvm_pio 
 
 
 
 

除VM Entry和VM Exit事件外，***的就是kvm_pio和 kvm_mmio，说明Windows确实有大量IO Port和MMIO操作，这也验证了在火焰图上所得出的结论。

在虚拟化里，IO Port或者MMIO都可能引起VM Exit，甚至是Heavy Exit。如果需要改善性能，一般都会尽量避免这种情况，至少避免Heavy Exit.

具体访问哪些IO Port和MMIO导致的VM Exit?

对于这个问题，KVM模块已经加了很多trace event，上面的kvm_stat也是利用这些trace event，只是并没有把具体trace event信息打印出来。为了获取trace-event的信息，有很多前端工具，如trace-cmd、perf，都是不错的选择。

• 查看所有kvm模块的trace event

 
 
 
 

  
  
  
  
[xs3c@devhost1 ]# trace-cmd list -e | grep kvm 
  
  
  
  
kvmmmu:kvm_mmu_pagetable_walk 
  
  
  
  
kvmmmu:kvm_mmu_paging_element 
  
  
  
  
kvmmmu:kvm_mmu_set_accessed_bit 
  
  
  
  
kvmmmu:kvm_mmu_set_dirty_bit 
  
  
  
  
kvmmmu:kvm_mmu_walker_error 
  
  
  
  
kvmmmu:kvm_mmu_get_page 
  
  
  
  
kvmmmu:kvm_mmu_sync_page 
  
  
  
  
kvmmmu:kvm_mmu_unsync_page 
  
  
  
  
kvmmmu:kvm_mmu_zap_page 
  
  
  
  
kvm:kvm_entry 
  
  
  
  
kvm:kvm_hypercall 
  
  
  
  
kvm:kvm_pio 
  
  
  
  
kvm:kvm_cpuid 
  
  
  
  
kvm:kvm_apic 
  
  
  
  
kvm:kvm_exit 
  
  
  
  
kvm:kvm_inj_virq 
  
  
  
  
kvm:kvm_inj_exception 
  
  
  
  
kvm:kvm_page_fault 
  
  
  
  
kvm:kvm_msr 
  
  
  
  
kvm:kvm_cr 
  
  
  
  
kvm:kvm_pic_set_irq 
  
  
  
  
kvm:kvm_apic_ipi 
  
  
  
  
kvm:kvm_apic_accept_irq 
  
  
  
  
kvm:kvm_eoi 
  
  
  
  
kvm:kvm_pv_eoi 
  
  
  
  
kvm:kvm_write_tsc_offset 
  
  
  
  
kvm:kvm_ple_window 
  
  
  
  
kvm:kvm_vcpu_wakeup 
  
  
  
  
kvm:kvm_set_irq 
  
  
  
  
kvm:kvm_ioapic_set_irq 
  
  
  
  
kvm:kvm_ioapic_delayed_eoi_inj 
  
  
  
  
kvm:kvm_msi_set_irq 
  
  
  
  
kvm:kvm_ack_irq 
  
  
  
  
kvm:kvm_mmio 
 
 
 
 

KVM模块添加了许多trace event的点，这里只抓起其中两个——kvm:kvm_pio和kvm:kvm_mmio。

 
 
 
 

  
  
  
  
trace-cmd-pio-mmio 
 
 
 
 

通过统计发现主要访问的：

• IO Port是0x608和0xc050;
• MMIO是0xFEE003xx

经由qemu info mtree命令，可以查看IO Port 608、c050以及FEE003xx分别对应的具体设备。

• IO Port

 
 
 
 

  
  
  
  
0000000000000608-000000000000060b (prio 0, RW): acpi-tmr 000000000000c040-000000000000c07f (prio 1, RW): virtio-pci 
 
 
 
 

• MMIO

 
 
 
 

  
  
  
  
00000000fee00000-00000000feefffff (prio 4096, RW): icc-apic-container 
 
 
 
 

c050可以忽略，这个被Virtio Block来做VM Exit。

到目前为止，可以判断出wnidows大量读取ACPI Power Manager Timer以及访问APIC寄存器，进而导致过多vm exit产生，消耗大量CPU资源，因此就可以具体讨论两个问题：

• 如何减少读取ACPI PM Timer寄存器而引起的VM Exit;
• 如何减少访问APIC MMIO导致的VM Exit。

如何减少读取ACPI PM Timer而引起的VM Exit?

从虚拟化层优化的思路来说，减少IO Port引发的VM Exit通常会考虑是否可以利用Para-virtulization替换Full-virtualization 以达到目的，来看Windows在这方面是如何做的。

从Windows 7开始，微软为了使Windows 操作系统能够在HyperV得到更好性能，特意为Windows系统做了很多虚拟化方面的增强工作，其中就包括这里可以利用到的HyperV Timer，这个特性类似于Linux中的kvmclock。

从当前的支持情况来看：

• Windows 7
• Windows 7 SP1
• Windows Server 2008 R2
• Windows Server 2008 R2 SP1/SP2
• Windows 8/8.1/10
• Windows Server 2012
• Windows Server 2012 R2

qemu和libvirt添加了HyperV Timer的支持，所以可以直接通过libvirt使能HyperV Timer。另外，KVM里很早也支持了HyperV Timer，只是客户的宿主机内核版本并不支持该功能，所以需要为客户升级UCloud自己维护的内核版本。

如何减少APIC ACCESS而引起VM Exit?

Intel CPU也已经支持apic-v，同样升级到UCloud自己维护的内核版本来解决。

最终效果

 
 
 
 

  
  
  
  
win-fio-good 
 
 
 
 

 
 
 
 

  
  
  
  
win-good 
 
 
 
 

总结

从这个案例可以看出，跟物理环境相比，在虚拟化环境下，WindowsIO性能较差时，并不一定真正是IO路径出现问题，可能是一些虚拟化性能的问题对IO性能造成了很大影响。

【本文是专栏机构作者“大U的技术课堂”的原创文章，转载请通过微信公众号(ucloud2012)联系作者】

 戳这里，看该作者更多好文

分享标题：技术分享：虚拟化环境下解析WindowsIO性能
标题URL：http://www.shufengxianlan.com/qtweb/news17/253667.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联