@
764664 那篇《64MB 的 VPS 能支持多少访问量?》指的不是openvz, 例子里有swap呢, 那会儿openvz可没vzswap, 看了下占用,48mb的内存+55mb的swap,算100mb吧, 就拿100mb举个例子,一个没关闭innodb的mysql使用默认配置启动后加上系统本身进程开销大致在90mb左右,而openvz里是直接奔400mb去的。事实上,你要留意vpsee的大部分文章的话, 你会发现vpsee从来没把openvz当成可用的vps方案过
我就总结一下openvz的缺点吧
1, 超售, 除了mediatemple的vps和servint的独立服务器应该找不到不超售的openvz了, 江湖传说不超售的ramhost曾经一度推出高级方案后承认原先超售了2倍, 后来高级方案就不见了,又重新搞了kvm方案
2, 内存计算问题, 也就是上面说的
3, 进程崩溃,数据丢失。 比如用了innodb的mysql, mongodb(openvz下启动就会警告你会丢数据), redis都有可能随时崩掉进程,数据全丢,具体触发概率视RP而定, 甚至还有java, buyvm曾经一度把使用java的用户集中转移到专用的node, 让他们自生自灭
4, 硬盘, openvz并不是真正的vps, 而只是一个chroot加强版的方案, 所以访问硬盘文件并不像其他虚拟化方案一样是访问块文件, 当node用户很少的时候效率很赞(少了一层嘛), 当node用户很多的时候, 那就完了(处理一个文件在一个块文件里seek总好过在一个物理硬盘里不停蹿来蹿去效率高吧)。 所以,无论中外,即便做了raid10, openvz机器整个硬盘数据彻底丢的事件也是月月不绝。 另外,还有硬盘超售, openvz就算只有1mb剩余空间,都能卖给用户100g, 至少我在buyvm, burst, hostrail都碰到过昨天看硬盘还正常,第二天就彻底没空间的事, 如果碰到重要数据的写入, 后果不堪设想啊
5, 性能限制。 openvz的性能限制完全是摆设, 根本限不死的, 所以unixbench数据再高, 碰到共享相同cpu核心的邻居玩玩科学运算,或者挂挂bt,pt什么的, 一样只是痿了
6, burst内存的争议, 除了"
burst.net"这种不存在burst内存的openvz, 其他大部分vps商关于burst内存根本没有统一的说法, 但是大部分遵循一点, 就是node上用户少,随便你用, 用户一多,内存快不够了, 那你长时间占用burst内存的进程会被母鸡"暗杀"