题 x86 / x64虚拟化有多少开销?


对于使用英特尔硬件虚拟化的Win64主机和Linux64客户机,x86 / x64虚拟化(我可能会使用VirtualBox,可能是VMWare,绝对不是半虚拟化)有多少开销?

  • 纯粹受CPU限制的用户模式64位代码

  • 纯粹受CPU限制的用户模式32位代码

  • 文件I / O到硬盘驱动器(我主要关心吞吐量,而不是延迟)

  • 网络I / O.

  • 线程同步原语(互斥,信号量,条件变量)

  • 线程上下文切换

  • 原子操作(使用 lock 前缀,像比较和交换的东西)

我主要对硬件辅助x64案例(英特尔和AMD)感兴趣,但也不介意听到无辅助的二进制翻译和x86(即32位主机和客户)案例。我对半虚拟化不感兴趣。


22
2018-04-20 23:48




(1)“x86”表示32位。您将无法运行64位代码。 AMD64(也称为x64)虚拟化具有不同的限制,因为它需要硬件扩展。 (2)您的意思是通过二进制转换(仅限x86)或硬件辅助虚拟化(VT)进行x86虚拟化吗? - Skyhawk
@Miles:我已经澄清了这个问题。 - dsimcha


答案:


我发现像你这样的问题没有简单而绝对的答案。每个虚拟化解决方案在特定性能测试中的行此外,磁盘I / O吞吐量等测试可以在许多不同的测试(读,写,重写......)中进行拆分,结果将因解决方案和方案而异。这就是为什么将一个解决方案指向磁盘I / O最快的原因并不容易,这就是为什么像磁盘I / O的开销这样的标签没有绝对的答案。

在尝试查找不同基准测试之间的关系时,它会变得更加复杂。我测试过的解决方案都没有在微操作测试中表现出色。例如:在VM内部,对“gettimeofday()”的单次调用平均需要比硬件上多11.5倍的时钟周期。虚拟机管理程序针对现实世界的应用程序进行了优化,并且在微操作方面表现不佳。这可能不是您的应用程序的问题,可能更适合作为真实世界的应用程序。我的意思是通过微操作任何花费不到1,000个时钟周期完成的应用程序(对于2.6 GHz CPU,1,000个时钟周期花费在385纳秒或3.85e-7秒)。

我对x86架构的数据中心整合的四个主要解决方案进行了广泛的基准测试。我做了近3000次测试,比较了VM内部的性能和硬件性能。我称之为'开销'是在VM内测量的最大性能差异,在硬件上测得的最高性能。

解决方案:

  • VMWare ESXi 5
  • Microsoft Hyper-V Windows 2008 R2 SP1
  • Citrix XenServer 6
  • 红帽企业虚拟化2.2

客户操作系统:

  • Microsoft Windows 2008 R2 64位
  • 红帽企业Linux 6.1 64位

测试信息:

  • 服务器:2X Sun Fire X4150,每个都有8GB RAM,2X Intel Xeon E5440 CPU和4个千兆以太网端口
  • 磁盘:通过千兆以太网的iSCSI上的6X 136GB SAS磁盘

基准软件:

  • CPU和内存: Linpack基准 对于32位和64位。这是CPU和内存密集型的。

  • 磁盘I / O和延迟:Bonnie ++

  • 网络I / O:Netperf:TCP_STREAM,TCP_RR,TCP_CRR,UDP_RR和UDP_STREAM

  • 微操作: rdtscbench:系统调用,进程间管道通信

平均值使用以下参数计算:

  • CPU和内存:AVERAGE(HPL32,HPL64)

  • 磁盘I / O:AVERAGE(put_block,rewrite,get_block)

  • 网络I / O:AVERAGE(tcp_crr,tcp_rr,tcp_stream,udp_rr,udp_stream)

  • 微操作AVERAGE(getpid(),sysconf(),gettimeofday(),malloc [1M],malloc [1G],2pipes [],simplemath [])

对于我的测试场景,使用我的指标,四种虚拟化解决方案的平均结果是:

VM层开销,Linux guest:

  • CPU和内存:14.36%

  • 网络I / O:24.46%

  • 磁盘I / O:8.84%

  • 读取的磁盘延迟:慢2.41倍

  • 微操作执行时间:慢10.84倍

VM层开销,Windows guest:

  • 32位和64位的CPU和内存平均值:13.06%

  • 网络I / O:35.27%

  • 磁盘I / O:15.20%

请注意,这些值是通用的,并不反映具体案例场景。

请看一整篇文章: http://petersenna.com/en/projects/81-performance-overhead-and-comparative-performance-of-4-virtualization-solutions


24
2018-02-08 15:56



这篇文章已经过时了 - dyasny
For a 2.6 GHz CPU, 1,000 clock cycles are spent in 23 milliseconds,这不应该是1,000到2,600,000的简单划分来获得1,000个时钟周期的秒数吗? (不是23毫秒) - dvdvorle
@先生。快乐,你是对的。我得到385纳秒:1000/2600000000 = 0.000000385 = 385纳秒。你同意吗?感谢您指出了这一点。 - Peter Senna
@dyasny,我正在寻找硬件来重复更新版本的测试。知道我在哪里可以找到它吗? - Peter Senna
硬件可以在商店中轻松找到 - dyasny


您的问题中有太多变量,但我可以尝试缩小范围。让我们假设你使用VMware ESX,你做的一切都正确 - 最新的CPU支持虚拟化,具有半虚拟化存储的VMware工具和网络驱动程序,充足的内存。现在让我们假设您在此设置上运行单个虚拟机。根据我的经验,你应该有大约90%的CPU速度用于CPU绑定工作负载。我不能告诉你很多关于网络速度的信息,因为我们使用1Gbps链路并且我可以毫无问题地使其饱和,但是10Gbps链路可能会有所不同,但我们没有任何这些链路。存储吞吐量取决于存储类型,我可以通过本地存储获得约80%的存储吞吐量,但对于1Gbps NFS,它接近100%,因为网络是这里的瓶颈。无法说明其他指标,您需要使用自己的代码进行实验。

这些数字非常近似,它在很大程度上取决于您的负载类型,硬件和网络。当您在服务器上运行多个工作负载时,它会变得更加模糊。但我在这里要说的是,在理想条件下,你应该能够接近90%的本机性能。

另外根据我的经验,高性能应用程序的更大问题是延迟,对于客户端服务器应用程序尤其如此。我们有一个计算引擎,可以接收来自30多个客户端的请求,执行简短的计算并返回结果。在裸机上,它通常将CPU推至100%,但VMware上的同一服务器只能将CPU加载到60-80%,这主要是因为处理请求/回复的延迟。


4
2018-04-21 05:09



我可以从经验中说,使用单个VM饱和10GbE链接非常困难。我们已经使用了VMWare FT,它可以轻松地在10Gbe上自行饱和1Gbps链路,但它并没有接近饱和。 - Mark Henderson♦


我没有深入研究基本原语(如上下文切换和原子操作)的性能,但这是我最近使用不同虚拟机管理程序进行的暴力测试的结果。它应该表明如果你主要是CPU和RAM带宽有限,你可能会期望什么。

http://www.altechnative.net/2012/08/04/virtual-performance-part-1-vmware/


0
2017-08-07 13:25



你有一些关于Xen和KVM的信息真是太好了......但是最流行的两个Hypervisor怎么样?!他们完全失踪了。而且你已经包含了几个Type 2 Hypervisors,没有理智的SysAdmin会将它用于生产。 - Chris S
投票结果。链接已经死了。 - Tim Duncklee