记贰回虚拟化环境下Windows IO性能的解析

前言
趁着云计算技巧与服务的迈入和提升,更多的客户选择将事情布局到云端。但由于引入了虚拟化层,在事情布局进程中不时会赶上IO难点,日常也不错调节和测试。本文首要介绍利用perf、systemtap等工具,帮衬1位托管云客户调节和测试IO品质难点,来分析虚拟环境下Windows
IO的个性。

标题应运而生
有一次,托管云客户自身搭建了虚拟化环境,在同一台宿主机上创制windows 二零零六PAJERO2 和 Centos6.5虚拟机,用fio分别测试其人身自由读质量,windows 二〇〇九PRADO2的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
测试结果

图片 1

win_fio1
• 云主机IO栈

图片 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花了多久?
幸运的是,StefanHajnoczi已经为QEMU添加了Tracing的特色,由此能够很有利的总结出QEMU从收到到二个IO请求到成功所用的具体时间长度。

图片 3

从上述计算来看,平均IO完毕时间在130us,因而近年来解除QEMU
层造成太高延时的熏陶。其它,假使关切那种动态Tracing的overhead,从测试观望上海高校概类似十分二。
排除队列和延时题材,或者导致影响的也只有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

图片 4

win_fio1
从上航海用教室来看,QEMU主线程的cpu负载已经高达90%以上,就像符合on
cpu类题材。常常来说,化解那类难点最佳的章程正是用perf进度采集样品,然后生成火焰图,因为首先查看CPU具体消耗在如何位置是1个不利的精选。
perf record -a -g -p 36256 sleep 20
转移火焰图:

图片 5

win2008-bad
能够领会的看到,cpu超越50%消耗都以KVM的操作,个中最要害的损耗是vmx_handle_exit。(真实的火焰图是三个矢量图,用浏览器查看很简单确认)。那里引起vmx_handle_exit主要有两点:
访问IO Port(handle_pio)
访问 MMIO(handle_apic_access)
既是KVM模块占了绝超越二分一,那就更希望精晓测试时KVM的真实表现,通过另2个工具(kvm_stat)能够完结。

图片 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。

图片 7

trace-cmd-pio-mmio

透过总结算与发放现根本走访的:
IO Port是0x608和0xc050;
MMIO是0xFEE003xx
经由qemu info mtree命令,能够查阅IO Port
60⑧ 、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 提姆er寄存器而滋生的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系统都带有虚拟化增强效用,越来越多的信息在微软官方网站。
2015年,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?
AMD CPU也曾经支撑apic-v,同样升级换代到UCloud自个儿维护的根本版本来化解。
最终效果

图片 8

win-fio-good

图片 9

win-good

总结
从这么些案例可以见见,跟物理环境相比较,在虚拟化环境下,Windows
IO质量较差时,并不一定真就是IO路径出现难点,恐怕是有的虚拟化品质的难题对IO质量招致了非常的大影响。

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

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

相关文章