一、前言

隨著云計算技術與服務的發(fā)展和進步，越來越多的客戶選擇將業(yè)務部署到云端。但由于引入了虛擬化層，在業(yè)務部署過程中經常會遇到IO問題，通常也不易調試。本文主要介紹利用perf、systemtap等工具，幫助一位托管云客戶調試IO性能問題，來分析虛擬環(huán)境下Windows IO的性能。

二、問題出現

有一次，托管云客戶自己搭建了虛擬化環(huán)境，在同一臺宿主機上創(chuàng)建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 

云主機環(huán)境下，整個IO棧相對較長，涉及到Guest OS中的應用層/文件系統(tǒng)/Block層以及驅動層，虛擬化層，宿主機OS文件系統(tǒng)/Block層以及驅動層。因為涉及面多，所以其中任何一個環(huán)節(jié)出現問題都會造成性能下降，也為做IO的Tracing增加了難度。

從這次得到的信息來看，首先排除了宿主機文件系統(tǒng)和Block層以及驅動層的問題，因為同樣情況的配置，Linux系統(tǒng)并沒有問題。

所以目前主要集中于兩點

• Guest OS(Windows系統(tǒng))
• fio程序
• 文件系統(tǒng)/Block layer
• VirtIO Block驅動 虛擬機為Guest OS提供的是Virtio Block設備
• QEMU

如何排除QEMU的嫌疑?

對于IOPS的性能問題，很容易想到兩種可能性:

• IO延時過高
• 設備支持IO隊列太短

在隊列的問題方面，Linux和Windows虛擬機對應的Virtio Block設備都是一樣的，那么就需要確認延時問題。

QEMU 完成Block IO花了多長時間?

幸運的是，Stefan Hajnoczi已經為QEMU添加了Tracing的特性，因此可以很方便的統(tǒng)計出QEMU從接收到一個IO請求到完成所用的具體時長。

從上述統(tǒng)計來看，平均IO完成時間在130us，由此暫時排除QEMU 層造成太高延時的影響。另外，如果關注這種動態(tài)Tracing的overhead，從測試觀察上大致接近20%。

排除隊列和延時問題，可能造成影響的也只有Guest OS了。

VirtIO Block驅動的問題?

至少更新到***穩(wěn)定版本的Virtio-Win驅動，仍然存在同樣的問題。

Windows 文件系統(tǒng)/Block層的問題?

原生Windows系統(tǒng)在確認后并沒有做任何配置上的修改。

fio測試程序的問題

為什么Linux上fio沒有問題呢?

四、兩種可能性

在性能排查過程中，總是很容易陷入死局，經常會問到底是哪兒出了問題?因此一切可能影響的因素似乎都沒有做任何變動。從經驗來看，大部分性能問題都可以分成兩種可能:

• on cpu
• off cpu

重新來看這個問題 ，在基本排除IO延時問題后，對應的問題還有兩種可能性：

• CPU極其忙碌，但是大部分時間并不是在做IO處理;
• CPU經常處于空閑狀態(tài)，那相應的也沒有主要在處理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 

通過統(tǒng)計發(fā)現主要訪問的：

• 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?

從虛擬化層優(yōu)化的思路來說，減少IO Port引發(fā)的VM Exit通常會考慮是否可以利用Paravirtulization替換Full-virtualization 以達到目的，來看Windows在這方面是如何做的。

從Windows 7開始，微軟為了使Windows 操作系統(tǒng)能夠在HyperV得到更好性能，特意為Windows系統(tǒng)做了很多虛擬化方面的增強工作，其中就包括這里可以利用到的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系統(tǒng)都包含虛擬化增強功能，更多的信息在微軟官方網站。

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自己維護的內核版本來解決。

五、最終效果

win-fio-good 

win-good 

六、總結

從這個案例可以看出，跟物理環(huán)境相比，在虛擬化環(huán)境下，Windows IO性能較差時，并不一定真正是IO路徑出現問題，可能是一些虛擬化性能的問題對IO性能造成了很大影響。

【本文是51CTO專欄機構作者“大U的技術課堂”的原創(chuàng)文章，轉載請通過微信公眾號(ucloud2012)聯系作者】

 戳這里，看該作者更多好文