记一次虚拟化环境下Windows IO性能的解析

企业动态
本文主要介绍利用perf、systemtap等工具,帮助一位托管云客户调试IO性能问题,来分析虚拟环境下Windows IO的性能。

记一次虚拟化环境下Windows IO性能的解析

一、前言

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

二、问题出现

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

• 客户测试用的fio 配置

  1. [global] 
  2.  
  3. ioengine=windowsaio 
  4.  
  5. direct=1 
  6.  
  7. iodepth=64 
  8.  
  9. thread=1 
  10.  
  11. size=20g 
  12.  
  13. numjobs=1 
  14.  
  15. [4k] 
  16.  
  17. bs=4k 
  18.  
  19. filename=d:test.img 
  20.  
  21. rw=randread 

三、测试结果

  1. win_fio1 

云主机IO栈

云主机IO栈

  1. 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请求到完成所用的具体时长。

QEMU 完成Block 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消耗情况。

  1. top -H -p 36256 

  1. win_fio1 

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

  1. perf record -a -g -p 36256 sleep 20 

生成火焰图:

生成火焰图

  1. win2008-bad 

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

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

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

  1. 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

  1. [xs3c@devhost1 ]# trace-cmd list -e | grep kvm 
  2.  
  3. kvmmmu:kvm_mmu_pagetable_walk 
  4.  
  5. kvmmmu:kvm_mmu_paging_element 
  6.  
  7. kvmmmu:kvm_mmu_set_accessed_bit 
  8.  
  9. kvmmmu:kvm_mmu_set_dirty_bit 
  10.  
  11. kvmmmu:kvm_mmu_walker_error 
  12.  
  13. kvmmmu:kvm_mmu_get_page 
  14.  
  15. kvmmmu:kvm_mmu_sync_page 
  16.  
  17. kvmmmu:kvm_mmu_unsync_page 
  18.  
  19. kvmmmu:kvm_mmu_zap_page 
  20.  
  21. kvm:kvm_entry 
  22.  
  23. kvm:kvm_hypercall 
  24.  
  25. kvm:kvm_pio 
  26.  
  27. kvm:kvm_cpuid 
  28.  
  29. kvm:kvm_apic 
  30.  
  31. kvm:kvm_exit 
  32.  
  33. kvm:kvm_inj_virq 
  34.  
  35. kvm:kvm_inj_exception 
  36.  
  37. kvm:kvm_page_fault 
  38.  
  39. kvm:kvm_msr 
  40.  
  41. kvm:kvm_cr 
  42.  
  43. kvm:kvm_pic_set_irq 
  44.  
  45. kvm:kvm_apic_ipi 
  46.  
  47. kvm:kvm_apic_accept_irq 
  48.  
  49. kvm:kvm_eoi 
  50.  
  51. kvm:kvm_pv_eoi 
  52.  
  53. kvm:kvm_write_tsc_offset 
  54.  
  55. kvm:kvm_ple_window 
  56.  
  57. kvm:kvm_vcpu_wakeup 
  58.  
  59. kvm:kvm_set_irq 
  60.  
  61. kvm:kvm_ioapic_set_irq 
  62.  
  63. kvm:kvm_ioapic_delayed_eoi_inj 
  64.  
  65. kvm:kvm_msi_set_irq 
  66.  
  67. kvm:kvm_ack_irq 
  68.  
  69. kvm:kvm_mmio 

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

  1. trace-cmd-pio-mmio 

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

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

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

IO Port

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

MMIO

  1. 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通常会考虑是否可以利用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。

  1. <clock ...>   
  2.      
  3.     <timer name='hypervclock' present='yes'/>   
  4.  
  5. </clock> 

 

另外,KVM里很早也支持了HyperV Timer,只是客户的宿主机内核版本并不支持该功能,所以需要为客户升级UCloud自己维护的内核版本。

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

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

五、最终效果

  1. win-fio-good 

  1. win-good 

六、总结

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

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

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

责任编辑:赵宁宁 来源: 51CTO专栏
相关推荐

2017-06-16 15:18:15

虚拟化WindowsIO

2011-08-12 09:30:02

MongoDB

2023-01-05 11:44:43

性能HTTPS

2023-12-13 09:01:40

2023-04-26 12:48:58

.NET程序类型

2020-08-10 11:00:02

Python优化代码

2021-11-11 16:14:04

Kubernetes

2021-03-01 06:14:50

环境高并发延迟

2011-09-27 10:35:44

2013-04-01 10:27:37

程序员失业

2011-02-22 09:29:23

jQueryJavaScript

2023-06-07 07:31:04

PC端app脱壳技巧

2019-03-15 16:20:45

MySQL死锁排查命令

2021-12-20 10:15:16

zip密码命令网络安全

2013-01-17 10:31:13

JavaScriptWeb开发firebug

2021-05-13 08:51:20

GC问题排查

2020-06-05 08:53:31

接口性能实践

2022-01-07 11:48:59

RabbitMQGolang 项目

2020-10-30 14:11:38

服务器SDK堆栈

2014-08-11 09:31:52

点赞
收藏

51CTO技术栈公众号