Xen与OpenVZ技术性能对比

准备购买一台VPS,对比了多家VPS提供商，国外的、国内的，注意纠结于究竟是Openvz好还是Xen好的问题，于是查阅了一些资料，得到一些心得，分享一下

下面的这篇翻译自http://hostingfu.com/article/xen-or-openvz，Observer进行了翻译，本人进一步加了注释

一、Openvz和Xen的技术规格分析

1.Xen与Openvz的区别

Xen和Openvz同样是虚拟化主机技术，区别在于Xen是半虚拟化技术，它并不是一个真正的虚拟机，而是相当于自己运行了一个内核的实例，可以自由的加载内核模块，虚拟的内存和IO，稳定而且可预测。Openvz则是操作系统级别的虚拟化技术，是底层操作系统上的一层应用，这意味着易于理解和低权重开销，一般来说也意味着更优的性能。

这里有一个问题，可以看到实际上openvz因为免去了大量的公共开销，理论上来说性能会比xen更好。为什么大家都会认为openvz过分压榨性能呢？我认为是因为openvz配置起来比较灵活，给黑心 openvz服务商改低限制的机会。

比如mediatemple，号称512M内存的dv方案，kmemsize才12M，不了解的人看了512M觉得很哈皮啊，可是使用的时候一般这512M能分到你手里一半就不错了。此消彼长，所以才会有xen 能更好地利用机器性能的错觉

2.Openvz的内核模型

首先当OpenVZ的主机说“256MB的保证”，它实际上意味着约232MB的“privvmpages”，14M的“kmemsize”和其他杂项资源。当应用程序调用 malloc（）分配的内存将被添加到“privvmpages”。

当“privvmpages”超过限制，malloc（）将失败并返回一个NULL。当主机服务器内存用光了，然后虚拟环境下的进程超过 “oomguarpages”的将被终止。

OpenVZ的内存管理方法既有问题也有优势。最大的问题之一是内存容量的应用程序使用的内存和应用程序实际上分配到的内存是不同的，不同的应用程序他们的差别可能会很大。以Java为例，它通常分配一大块的内存，但是，它可能只使用一小部分分配的内存。如果privvmpages受限，java会立即停止运行。调整参数可以解决一部分问题，但它处理得绝对没有Xen来得干净利落。事实上，几乎所有使用内存分配的应用程序都会受OpenVZ这个问题的影响。

/proc/meminfo 本身也有问题。虽然OpenVZ的已经为内存进行了虚拟，但是用”free”命令依然会返回主机的内存。这样就会使小内存的openvz的vps无法运行诸如java或者gcc编译这样的程序。

OpenVZ的内存模型的优点是， 它容易理解： 你几乎就只有privvmpages受限。与专用的服务器或Xen的服务器不一样的是，你的磁盘高速缓存和页面缓存并不计入您的总内存使用情况。因此，在一个没有过度销售的openvz主机上，由于拥有较大冗余的公共资源，它实际上可能会比同类规格的Xen的VPS表现更佳。

3.Xen的内存模型

Xen的系统模型更容易解释。256MB的Xen的VPS是就像一个256MB的专用服务器-该内存段是预留作VPS专用，没有其他VPS能够使用这部分内存，这就像一个真正的专用服务器。

此外，当内存不足时，VPS会使用Swap。一般每个VPS带有两倍大小的交换分区，当您的应用需要更多的内存，不常使用的页面从内存中被换出到交换分区，从而腾出使更多的房间。因此，256MB的Xen的VPS系统实际上共有768MB内存（256MB内存+ 512MB的交换空间），请相信我，交换空间是非常有用的，特别是处理突发的需求高峰时。

这么说来，Xen是永远远优于OpenVZ？不然，你的256MB的VPS理论可以使用高达768MB内存，而实际上内核，高速缓存，缓冲，他们都占用内存。这部分系统开销也是可观的。另外，Swap会严重降低性能。

4.稳定性和可预测性

当内存耗尽时，xen和openvz表现大相径庭。xen会把不常用的内存页面换入Swap，这将大大降低性能，当Swap也用尽，那么xen的系统会响应得越来越慢，就像一台真实的服务器一样。

而openvz一旦内存用尽，则会突然死亡：开不出新的程序，只能等待系统资源可用。更有甚者，本来运行的好好的程序也可能因为不断增长而超过限制，然后突然死亡。这就像开车开到70码，然后突然撞墙上了，一般会死得很惨。

毫无疑问这点上我倾向于xen技术，可预测，稳定。

5.结论

如果xen和openvz一样贵，我肯定选xen，因为可预测性，即使openvz打8折，我还是追求稳定。

上面的话总结一下，得出几个结论：

1、XEN比openvz主机对买家更有利，比如分配给你512M内存后，这一部分内存就从服务器上专门划给你了，别人将无法使用，而openvz则是共用内存，比如分配给你512M内存是指最大你能使用512M内存，比如你占用了200M内存，那么就只从物体内存中分配200M给你，所以卖家非常容易在服务器上面超卖！

2、openvz更高效，xen是硬件底层虚拟，更接近真实服务器，而openvz是操作系统虚拟，虚拟服务自身占用内存少，同样的程序执行效率更高！

3、如果购买openvz应看卖家是否会超卖，应选择良好声誉明确申明不会超卖的

4、如果购买xen主机，应同时关注swap大小

5、测试VPS主机性能使用Unixbench（很多人不知道），国外非常流行这个东西！

这是它的一些参数说明

dhry2reg 内存的register性能

whetstone-double 双精度浮点性能

execl execl call性能

fstime 文件系统性能

fsbuffer 文件系统性能

fsdisk 文件系统性能

pipe 管道(pipe)的性能

context1 管道上下文切换的性能

spawn 创建进程的性能

shell shell并发性能

syscall 系统调用性能

6、VPS用途：服务器、软交换、代理和反向代理、离线B-T下载等等

7.通常一般的使用条件下，两者性能应该相差不大.
----------------------------------------------------------------------------------

Xen or OpenVZ VPS?

I have been a VPSLink customer for about as long as they have been offering the service — since June 2006 I think — although I rarely blogged about them here. Recently I had an opportunity to test out their recently launched Xen VPS hosting. VPSLink now offers both OpenVZ and Xen based VPS hosting at the same price point, and I will be reviewing their Xen offering here shortly. However I would like to look into an obvious question — Xen or OpenVZ VPS — which one is suitable for me? I will be looking at the differences between Xen and OpenVZ especially in memory model, and how it is affecting us the VPS customers.

Xen and OpenVZ — What’s The Difference?

While both Xen and OpenVZ are open source server virtualisation technology, there exists some big differences between the two. I think potential VPS customers might need to check the applications that need to be hosted to determine which one is the preferable virtualisation technology.

On one hand you have Xen, a para-virtualisation platform that gives you much of the dedicated server behaviour. You run your own instance of Linux kernel, you can load your own kernel modules, you have properly virtualised memory, IO and scheduler, and it’s stable and predictable. On the other hand you have OpenVZ, an operating-system level virtualisation system that is just a thin layer on top of the underlying OS. It is simple to understand, has lower overhead, which usually translates to better performance.
VPSLink is offering both OpenVZ and Xen VPS of similar specs at the same price. For example, I have a Link-3 OpenVZ VPS running CentOS 4.5, and it has 256MB memory, 10GB storage space and 300GB data transfer per month. VPSLink has also provided me a Link-3 Xen VPS for my review running the latest Ubuntu 7.10 ,and it too has 256MB memory, 10GB storage and 300GB data transfer per month. Same price for both — $24.95/month if you pay monthly. Now, which one should I buy?

OpenVZ Memory Model

First of all, when VPSLink’s OpenVZ Link-3 says “256MB guaranteed”, it actually means around 232MB of “privvmpages”, 14MB of “kmemsize” and other miscellaneous resources. When an application calls malloc(), the allocated amount will be added to “privvmpages”. However when “privvmpages” hits the limit, malloc() will fail with a NULL. When the host server ran out of memory, then processes in VE (virtual environment, OpenVZ’s term for a VPS) that exceeded “oomguarpages” will be terminated, although I do not think it will ever apply to VPSLink.
There are a few problems and a few advantages with OpenVZ’s approach to memory management. One of the biggest problem is the amount of memory an application uses and the amount of memory an application allocates is actually different, and the difference can vary a lot depending on the application. Take Java for example, it usually allocates a huge chunk of memory — usually everything it can see the host node has — but it might only use/commit a small fraction of allocated memory. It can usually render a Java program unusable as you will pretty much hit the privvmpages limit straight away. A bit of tweaking on bootstrapping parameters might fix it, but it is definitely not as clean as Xen or a dedicated server. In fact, almost all applications that use internal memory allocator suffer from this issue under OpenVZ.
Then there are issues associated with /proc/meminfo itself. While OpenVZ has already provided a way to virtualise it, “free” command on my OpenVZ VPS at VPSLink still shows the memory size of the host node. It makes some tasks, like running Java or heavy compilation with gcc almost impossible on a small VPS.
The advantage of OpenVZ’s memory model is that it is simple to understand — you are pretty much limited by only privvmpages on a VPSLink OpenVZ VPS. Unlike a dedicated server or Xen, your disk cache and your buffered pages are not counted against your overall memory usage. Therefore on an under-sold OpenVZ system with lots of cache and buffer memory on the host server, it might actually perform better than a similar spec’ed Xen VPS.

Xen Memory Model

Memory model for Xen VPS is much easier to explain. A 256MB Xen VPS is just like a 256MB dedicated server — that segment of memory is reserved for this VPS only, and no other VPS nodes can touch it. Like a real dedicated server, it counts only resident pages, i.e. only the memory blocks are allocated and used.
Moreover, what happens when you run out of memory? You VPS starts to swap. Each VPSLink Xen VPS comes with a swap partition that is twice the size of memory. When your application requires more memory, least-often used pages will be swapped out to make more rooms. Therefore a 256MB Xen VPS actually has 768MB of total memory (256MB RAM + 512MB swap), and believe me, swap space is very useful to handle that sudden spike of demand.
So Xen is always much better than OpenVZ? Not quite. While your 256MB VPS can theoretical use up to 768MB of memory, in reality

1. Kernel, cache, buffer — they all take up memory.
2. Swapping kills performance.

Yes, you can tune the swappiness so you can keep on reducing cached and buffers without touching swap, however performance will suck. On the other hand you can bump up memory usage on an OpenVZ VPS all the way to the privvmpages limit without much degrading of performance, provided the host node still has room to spare. It is a good thing but can also a bad thing, which I will explain later.

Performance vs. Predictability

At the end it comes down to performance and predictability, and my preference has always been with Xen.
While Xen has more overhead thus possibly slower VPS, its out-of-memory behaviour is much more predictable than OpenVZ, and this predictability won me over. As I have already said, that OpenVZ will continue to perform well when its memory usage approaches the limit. However, if privvmpages has been exhausted, the next malloc() will return a NULL pointer, and depending on how the applications handle NULL pointer, they either die gracefully or die with a segmentation fault (usually the later). It is like driving at 100km/hour and then suddenly hits a brick wall. You do not even know that there is a memory shortage issue because everything just sails so smoothly.
On the other hand, when a Xen VPS used up free memory, it will start taking memory from buffers and cached pages. Then it will start swapping. And then it will finally die when the last bit of swap partition gets exhausted. Performance will start to degrade when it started swapping. The load will go up, and the server will get less and less responsive. Your Xen VPS will spend more of its time swapping pages in and out than actually handling tasks. Even if it dies at the end, it will be a very noticeable long struggle than a head-on smash…
… just like a dedicated server!
My preference? Predictable performance. I’ll rather have my sites slowing down to its knees, than having it crash and burn when the memory is exhausted.

What About Burstable Memory in OpenVZ?

“Burstable memory” in OpenVZ is overrated IMHO, as it makes the behaviour of your VPS even less predictable. It is often advised to set privvmpages (burstable amount) at twice the amount as vmguarpages (guaranteed amount) as allocated amount vs. used amount is usually 2:1. However it is not always the case. At work where we had lots of Java development it’s a bit like 5:1, but on my VPSLink OpenVZ VPS where it is mostly Lighttpd, MySQL and PHP, the ratio is about as low as 1.45:1.
Therefore out-of-memory could still happen when you have burstable (privvmpages) set to twice the guaranteed (vmguarpages). On the other hand, VPSLink’s “no burst, no swap” policy, i.e. making burstable amount the same as guaranteed amount, actually gives each VPS less memory to play with, at least it guarantees that when OOM occurs, no VE will be held responsible as all of them will be under their guaranteed limit.

Conclusion

By looking at OpenVZ and Xen’s memory model and their handling of out of memory situation, I am leaning towards Xen, if I am going out to buy a VPS now. Especially when they are sold at the same price per month at VPSLink, I personally cannot see why someone would prefer OpenVZ over Xen.
Except if there is a discount on OpenVZ VPS :)
I have seen a few promotions coupons from VPSLink (last one being 31% discount from Halloween) but none of them can be used on VPSLink’s Xen VPS. I for one will switch from OpenVZ to their Xen VPS in a heart beat, except I am still on the initial 50% discount for my OpenVZ VPS that is just too hard to let go :)
Alright. Enough Xen vs. OpenVZ.