谈VPS：Xen与OpenVZ性能测试到底孰优孰劣

2019-03-12 09:03:21来源： obmem.com 阅读 ()

因为最近在给VeryCD作山寨站点，这个可是有1G数据库的真家伙，可不是wordpress、没啥人气的discuz论坛等这种小菜可以比拟的，想必会在一定程度上考验VPS的性能。之前选VPS那个花钱如流水，买的多个VPS都还没到期，打算压榨一下他们的剩余价值。应用web.py框架的几台VPS/Shared Hosting中，一台rapidxen的128M Xen方案，一台ramhost的512M Openvz方案，一台stdyun.com的80M共享空间方案。

测试Xen vs Openvz vs Shared Hosting的性能比，用ab -n 1028 -c 128 addr来测，以response time（mean）为基准，他们的性能对比大约是0.8:28:6，这么个悬殊的差别，实在令我惊讶万分。

stdyun.com是专为python优化过的共享主机，本身load average比较低，能有6的表现也属不错；ramhost就是一个bt，从来没见过VPS性能那么猛的，根据我对数据的初步分析这么个站同时在线万人也不会有什么问题；而rapidxen则让我大跌眼镜。

诚然应该有相当部分的原因是rapidxen的方案内存比较小的关系，可是人家内存比你更小（80M）的标准云都表现比它强6倍，这无论如何有点说不过去。而且观察程序的内存占用，令人沮丧地发现，xen的内存占用达到了openvz的两倍之多，这让我强烈审视起网上流传的xen要比openvz好，能彻底利用主机性能的说法。

有了怀疑，就打算真的好好比较一下他们了，所有错误的观念都要摒弃，所有人云亦云都由我而止，Xen和Openvz到底孰优孰劣，真相只有一个，我追求的就是那尽可能无偏的结论。

本文打算从两个方面来比较Xen和Openvz的性能。第一是理论方面：根据强大的参考文献1，具体分析两个架构的优劣。第二是实践方面：大家一碗水端平了用真实的应用决胜负：既然内存不公平，那我就给你公平。根据参考文献2的廉价VPS列表，我挑选了Xen的内存512M的，价格最便宜的PhotonVPS（又是16刀，泪奔，做个测试成本真高）。

以下理论中，普通字是我对参考文献1的粗略翻译。

一、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表现更佳。

这实际上解答了我关于ramhost为啥那么牛叉的疑惑，因为据我所知ramhost是相当undersale的服务商，从他们的状态日志上可以看到，一般inactive内存都在2G以上，所以性能当然强劲了.

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折，我还是追求稳定。

有趣的是我虽然看了这篇文章，却得出了一个截然相反的结论。

不考虑黑心openvz服务商的问题。由于同样的程序在xen中占用内存比openvz两倍还多，xen总是很容易进入swap环节，从而在同样的配置下一般会性能更低。

对我来说用vps就是追求性价比的。像openvz那样撞墙？不怕，程序写写好，控制内存使用，一旦内存用尽，exception写写好，处理得漂亮一点就没事了。像xen那样跑车变成黄鱼车？这个提都别跟我提。

二、Openvz和Xen的实战比较

一、规格说明：

OpenVZ： Ramhost 512MB Plan

Xen： Photonvps 512MB Plan

二、Unixbench分数

很多人可能不知道这个东东，事实上这是国外测试VPS性能非常流行的一个软件。

虽然看上去山寨了点，但是是好东西。事实上，以性能为卖点的vps hosting公司大部分都会给出unixbench-wht-2的成绩来以示其牛叉。

例如：clustered，silverrack，等等。

这个分数的意义是你的性能与一台标准P233MMX （FreeBSD 2.x， 128MB RAM， SCSI 7200RPM）的性能比，越大越好。

他的一些测试项目如下

        dhry2reg    内存的register性能
        whetstone-double 双精度浮点性能
        execl       execl call性能
        fstime     文件系统性能
        fsbuffer    文件系统性能
        fsdisk      文件系统性能
        pipe        管道(pipe)的性能
        context1    管道上下文切换的性能
        spawn       创建进程的性能
        shell       shell并发性能
        syscall     系统调用性能

如果这样不直观的话，我来说一下我用过的一些VPS/shared host的unixbench成绩吧。

mediatemple dv($50的那个)   30-
    hostmonster basic               60+
    rapidxen 最低配                   60+
    我的IBM T43@ubuntu9.10     110+
    stdyun.com                        ~300

好的，那么进入正题，我所用的两家公司的openvz和xen的性能比较

Ramhost.us OpenVZ
-----------------------
                     INDEX VALUES
TEST                                        BASELINE     RESULT      INDEX

Dhrystone 2 using register variables        376783.7 9652226.8      256.2
Double-Precision Whetstone                      83.1     1335.8      160.7
Execl Throughput                               188.3     5379.2      285.7
File Copy 1024 bufsize 2000 maxblocks         2672.0   154554.0      578.4
File Copy 256 bufsize 500 maxblocks           1077.0    44083.0      409.3
File Read 4096 bufsize 8000 maxblocks        15382.0   818801.0      532.3
Pipe-based Context Switching                 15448.6   260826.7      168.8
Pipe Throughput                             111814.6 1144518.6      102.4
Process Creation                               569.3    15241.2      267.7
Shell Scripts (8 concurrent)                    44.8      989.8      220.9
System Call Overhead                        114433.5 1206388.1      105.4
                                                                 =========
     FINAL SCORE                                                     241.1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PhotonVPS Xen
-----------------
                     INDEX VALUES
TEST                                        BASELINE     RESULT      INDEX

Dhrystone 2 using register variables        376783.7 33564046.7      890.8
Double-Precision Whetstone                      83.1     1418.2      170.7
Execl Throughput                               188.3     5122.2      272.0
File Copy 1024 bufsize 2000 maxblocks         2672.0   145582.0      544.8
File Copy 256 bufsize 500 maxblocks           1077.0    40877.0      379.5
File Read 4096 bufsize 8000 maxblocks        15382.0 1367761.0      889.2
Pipe-based Context Switching                 15448.6   448013.6      290.0
Pipe Throughput                             111814.6 1703063.9      152.3
Process Creation                               569.3    15826.5      278.0
Shell Scripts (8 concurrent)                    44.8     1551.2      346.2
System Call Overhead                        114433.5 2237909.1      195.6
                                                                 =========
     FINAL SCORE                                                     336.8

其中PhotonVPS因为使用了8核，所以是用。/Run 8来测试的分数。

通过比较可以发现，两者的浮点磁盘性能什么的都差不多，差异巨大的在于register性能，因为8核寄存器比较多的关系吧大概，所以分数巨高无比。所以整体上PhotonVPS要比ramhost高出一大头。需要注意的是，并非所有的openvz主机和xen主机的性能都是如此，事实上，取决于不同服务商的配置和你所在节点的负载，性能会差异很大。例如mediatemple的类openvz系统分数就只有30，而rapidxen的xen系统分数就只有60，等等。

三、实际项目的性能比较

以SimpleCD为例，分别架设到ramhost和photonvps上。

SimpleCD项目简介：可以看作一个1G sqlite3数据库用python进行查询的项目，当然因为我程序写得不好，刚学着用数据库，数据库设计上有问题，再加上用的是比较悲剧的sqlite3，不太适合太大的数据库，所以性能很低。不过也好，正好用来测试VPS的性能，看openvz和xen在悲剧的数据系统下表现如何。

ramhost上数据库可以正常查询，第一次查询时间比较长，后来基本上都在1秒内。

photnxen上数据库不一定可以正常查询，经常出现超时现象。

这个事实非常奇怪，好奇之下我登录了sqlite3，测试单条指令的执行时间，事实上证明还是photonxen比较快。但是为什么网站方面会差那么多呢？原因我觉得是xen的内存问题。

补充，后来我换了mysql数据库，mysql比sqlite更烂，所以结论就很明显了，瓶颈就在内存上面。就如我之前推测的，xen的内存使用太大，很多隐性消耗下，web.py运行时占用了大量内存，导致作sqlite3查询时需要不停地swap，这样一来自然就要超时了。

本来还想用ab来测试并发性能的，但是这么一来就有点太欺负xen了，所以这个测试就不做了。

四、好好利用寄存器性能

这个算是题外话，因为不是所有的xen都像photnxen那么强大的。

为什么想到这个？是因为我用lzma压缩数据库时，photonxen要比ramhost快一点。

想想就知道原因了，这种压缩算法非常耗CPU，这时候寄存器性能就派上大用处了。

那么同理可以推测，它处理视频转换什么的那也应该是相当的拿手。

现在PSP/手机用的挺多，但是很多视频无法在手机上看，得转换以后再看。用自己的电脑转换太慢了，现在好了，只要用离线下载的方法下载资源到服务器，然后服务器自动运行脚本转换为MP4，然后自己再直接去服务器上拖，一举n得：

1.转换p2p下载为ftp下载