ACCESS记一糟虚拟化环境下Windows IO性能的分析

前言
趁着云计算技术及服务的升华以及升华,越来越多之客户选择以工作布局至云端。但出于引入了虚拟化层,在工作布局过程被不时会遇见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
测试结果

ACCESS 1

win_fio1
• 云主机IO栈

ACCESS 2

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请求到得所用底切实可行时长。

ACCESS 3

自上述统计来拘禁,平均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

ACCESS 4

win_fio1
由上图来拘禁,QEMU主线程的cpu负载已经上90%之上,似乎符合on
cpu类题目。通常来说,解决当时类似问题太好的艺术就是是用perf进程采样,然后转火焰图,因为首先查看CPU具体消耗在什么地方是一个正确的挑三拣四。
perf record -a -g -p 36256 sleep 20
转火焰图:

ACCESS 5

win2008-bad
好知晓的看,cpu大部分消耗都是KVM的操作,其中最为着重的损耗是vmx_handle_exit。(真实的火焰图是一个矢量图,用浏览器查看很容易确认)。这里引起vmx_handle_exit主要发生些许触及:
访问IO Port(handle_pio)
访问 MMIO(handle_apic_access)
既然如此KVM模块占了绝大多数,那就算重期望了解测试时KVM的真人真事表现,通过外一个器(kvm_stat)可以齐。

ACCESS 6

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。

ACCESS 7

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资源,因此即使足以切切实实讨论两独问题:
1.如何减少读取ACPI PM Timer寄存器而滋生的VM Exit;
2.安压缩访问APIC MMIO导致的VM Exit。

怎么样减少读取ACPI PM Timer而滋生的VM Exit?
自打虚拟化层优化的笔触来说,减少IO Port引发的VM
Exit通常会考虑是不是好下Paravirtulization替换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
这些Windows系统都饱含虚拟化增强力量,更多之信息在微软官方网站。
2014年,RedHat工程师Vadim Rozenfeld和Peter Krempa
分别吗qemu和libvirt添加了HyperV
Timer的支撑,所以可以直接通过libvirt使能HyperV Timer。

<clock …>

<timer name=’hypervclock’ present=’yes’/>

</clock>

另外,KVM里好早也支撑了HyperV
Timer,只是客户的宿主机内核版本并无支持该意义,所以要为客户升级UCloud自己维护的本版本。
•如何压缩APIC ACCESS而引起 VM Exit?
Intel CPU也曾支撑apic-v,同样晋级到UCloud自己维护的水源版本来化解。
末尾效果

ACCESS 8

win-fio-good

ACCESS 9

win-good

总结
自夫案例可以看出,跟物理环境比,在虚拟化环境下,Windows
IO性能比差时,并不一定真正是IO路径出现问题,可能是一对虚拟化性能的题材对IO性能造成了酷十分影响。

原稿地址:http://blog.ucloud.cn/archives/2409

https://my.oschina.net/u/3675312/blog/1529795

相关文章