说故事，并共享自己的 VPS 测试数据

（说在最前，下面是我的一片博客文章，说点关于自己和 VPS 服务器故事，如果没兴趣，可以直接看后面 VPS 测评）

不作死就不会死

我说的是我自己。

短短的半个月内，我的各个服务器遭受崩溃，网络问题，甚至直接整个崩溃，搞得自己是夜不能寐、神魂颠倒，有时候心想苍天啊、大地呀， blabla ……真是“不作死就不会死”。于是写篇日记，记录一下这个过程，顺便吐槽和点赞几个的服务商。

1 月 10 日

那天一大早起来就和老婆外出了，因为之前老婆身体不舒服，说好今天陪她去医院看看的。北京的医院，你懂得，得早起。到医院没多久，电话响了，一看是策划小伙伴的，他平时很少给电话，心想不好，果然，他说游戏服务器变得非常非常慢，不知道什么回事。我开始以为是网络问题，用手机上了一下游戏，发现进入游戏、打开公会界面（大量读取数据库），都慢的出奇，平时 2 秒钟响应，现在竟然几十秒，甚至有些时候直接触发超时断开网络。当时，我大脑立刻进入思维强烈运转模式，找寻解决办法，不过从外表看，我表情呆滞，心不在焉，行动缓慢，老婆还以为我魂丢了呢，陪她上医院，反倒是我生病了。

作为一个技术男，负责几个软件、游戏 ，需要随时随刻都能够连接服务器进行恢复，是必不可少技能。我立刻抄起手机 上去查看一下到底怎么了，其实，没有怎么，就是非常慢，还重启了一下服务器，导致玩家的聊天的信息丢失，但还是没有好，我预感到应该是母鸡出问题了，需要又一次搬家了。

这里稍微解释一下什么是母鸡，就是服务器提供商将一台主机切割出来多个虚拟主机，每个单独拿出来卖。有些服务商比较黑心，切割过多，卖出更多的钱，但是平均到每台虚拟机的性能就差了，要是和几个折腾帝共享，那完了。而我的那台主机估计刚好进驻一个折腾帝。倘若直接独占一个母鸡，那费用是几十倍于虚拟小鸡，小团队伤不起啊。

于是，老婆牵着低头操作手机的我，看病，付款，做检查，回诊……还算幸运，很快就弄完了。回去之后，我就着手把服务器迁移出去。刚才忘说了，我曾经多次迁移主机地址，换服务商，都是因为网络，当时使用的服务器提供商 HostHatch 在香港，就是因为网络质量蛮不错的，机器性能（一开始）不错，在香港待了几个月，都平安无事。仍然想在香港找主机服务器，哎，长话短说，从 HostHatch 跳出来，又不小心进了星空互联的坑，进去的时候，做的磁盘测试方法错了，导致游戏程序一进去就变成了小霸王，根本跑不起来。

是我自己作，没有想清楚，大部分香港服务器都是用来做“梯子”的，你上去跑游戏数据库，当然是作死，完了还用比较原始的方法测试（ dd ） ，而不是用更加准确的方法（ fio ），最后导致误判， 20 多 G 的数据传来传去，耽误了 3 、 4 个小时。最终还是选择了老牌 Linode 牛 X 服务商的新加坡数据中心。

1 月 11 日

陆续接到几个国内的高级玩家发来邮件，说服务器登陆不了，前一天的服务器问题让玩家们已经很担心了，游戏里面弥漫着一种幽怨的气息，现在移动到了新加坡，虽说服务商非常稳定，但是网络却是一大坑。当时自己抓耳挠腮，各种 google （我不用百度，谢谢），终于，上帝还是没有抛弃这个可怜的程序员，让我发现了使用香港服务器做跳板来过渡的方法。其实，我用的 CloudXNS 一直有一个功能，就是世界分区域解析 ip 地址，这样就可以让国外的玩家用原始的新加坡地址，而国内玩家用香港地址，这样两者都不耽误啦。

于是研究花了一个上午，做了一个跳板（ iptables 转发）。跳板还是放在星空互联香港——它本来就是干这个的。还真是，从语盒邮件到现在的语盒游戏，强烈的感觉到，如果把一个程序员逼上绝路，是什么事情都能干出来的。

1 月 20 日

早上起来一身爽啊，服务器放在稳定的 Linode ，又有香港做跳板，地震了都不怕。手机开机准备收邮件，马上发现了各种玩家邮件，说服务器上不了了，我看了一下，果然服务器挂了（一万匹草泥马在心中奔过），还是在凌晨 5 点的时候，到现在已经好几个小时了。

胡乱的洗漱、吃饭，然后奔到公司，查查到底是什么问题导致的，连牛逼的 Linode 都挂了，后来发现是触发了所谓的 OOM 机制，是从香港服务器转移过来的时候忘记更改参数了，消耗过多的资源，让系统把游戏程序给干掉了，真作死。导致整上午都没有好心情，玩家还各种骂，说我们的服务器是小霸王，还真是其乐无穷啊。

1 月 22 日

晚上，老婆去参加公司年会了，我给孩子洗完澡，一边等老婆，一边逛程序员论坛（ V2EX ），看到有人提问关于 Mongodb 数据库的问题，作为常年使用 Mongodb 的“高手”，得瑟一下，瞬间回复了解决方案，就在这时， 10 点 20 ，一个国外的玩家通过 BBM 问我，“ Server is down ？”， Oh shit ，怎么又挂了？！

上去一看，不好，刚回答 Mongodb 的问题，这边立刻自己的数据库挂掉了，你说不是“作”是什么？登录上去查看原因，发现是一个数据库的重要文件坏掉了，数据库不断出错。可能是因为服务器迁移次数太多， 20 多个 G ，网络传输的时候导致的；也可能是写硬盘的时候导致的，总之就是错误了。

天，数据库恢复不了了！所有玩家的档都会丢失，只能恢复到凌晨 4 点钟的每日备份数据，如果真是那样，我还不被玩家爆菊、手撕了不可。

既然现在我还能活着写完这篇日志，那就表示这个问题还是被我解决了的。好就好在，出现的问题文件虽然重要，但仅仅是很小一部分，我还可以吧数据库内容导出来，并且删除原来的问题文件，再导回去装的。 Linode 机器性能厉害，恢复很快，前前后后仅花了 40 分钟。当天晚上，我梦见各种服务器爆炸的场景，还有玩家跑过来问，“菊花呢！？”。

1 月 23 日

第二天，又来了另外的噩梦，收到用户的反馈，这次不是游戏，而是我的语盒邮件服务器崩溃了。真是“太刺激”了，有一种想哭的感觉。我试图简单重启一下看看到底什么回事，竟然发现连系统都无法进入，整个服务器硬盘就像被格式化了一样，大部分文件都丢失了，我勒个天！这个服务器我是放在另外一个知名的厂商 DigitalOcean 那里的，好在他们服务给力，求助了一下他们的技术支持，很快就给我如何恢复的方法，这里要赞一个。

遵循他们的指引，发现系统恢复成原来的样子是不可能了，但是可以把自己的数据拷贝出来。于是我又开了一个服务器，把重要的文件都拷贝出来，重新启动， OK 了。虽然说得很简单，但是从上午到下午搞了好几个钟头，因为语盒邮件我已经很久没有开发了，连启动的命令都差点忘了，代码虽然是开源的，但是仅仅打包都搞了挺久。

服务器好好的，挺稳定的为啥就挂了个底朝天呢？究其原因，就是之前 10 日出现的硬盘性能问题之后，我为了测试其他的服务器性能，都跑了一边新的方法（ fio ），谁知道，这个新方法，是把硬盘的所有操作都占用得出的，最后导致整个文件系统丢失格式。我有几台用来测试的服务器当时就挂掉了，没有引起我重视，而这台机器硬撑了十几天也嗝儿屁了。好吧，自己挖坑自己栽，“不作死就不会死”。

总结

坑踩了太多，不过对自己有了重新的认识：当被逼上绝路的时候，上帝会给再开一扇窗子，让你翻过去的。莫怕。

------------------------------------------我是测试数据的分割线-----------------------------------------------

使用 fio 进行测试（这个比较暴力，需要慎重，绝对会把数据弄坏，但是非常准确）：

yum install -y fio

4K 随机读写（ IOPS ）：
fio -filename=/dev/sdb -direct=1 -iodepth 64 -thread -rw=randrw -ioengine=libaio -bs=4K -numjobs=8 -runtime=120 -group_reporting -name=test
运行的时候，通过 df 命令看看是什么盘，然后把上面的 filename 参数改一下，如果不行，需要加 size 参数，需要去掉 filename 参数

自己机器上三星的 SSD 盘子，做个基准吧：

（ Windows 命令： fio.exe --size=1G --direct=1 --iodepth 64 --thread --rw=randrw --ioengine=windowsaio --bs=4k --numjobs=8 --runtime=120 --group_reporting --name=test ）
read : io=4099.3MB, bw=117351KB/s, iops=29337, runt= 35770msec
write: io=4092.8MB, bw=117165KB/s, iops=29291, runt= 35770msec

Linode KVM （ linode 一测试就丢失盘子文件， ls 命令都找不到了，估计是跑得太狠了）：

read : io=14451MB, bw=123300KB/s, iops=30824, runt=120019msec
write: io=14452MB, bw=123307KB/s, iops=30826, runt=120019msec

DigitalOcean KVM ：

read : io=3506.6MB, bw=29915KB/s, iops=7478, runt=120030msec
write: io=3509.4MB, bw=29939KB/s, iops=7484, runt=120030msec

StarryDNS KVM （被他坑死）：

read : io=98508KB, bw=836329B/s, iops=204, runt=120613msec
write: io=96208KB, bw=816802B/s, iops=199, runt=120613msec

UCloud 高速盘：

read : io=12180MB, bw=103927KB/s, iops=25981, runt=120010msec
write: io=12180MB, bw=103931KB/s, iops=25982, runt=120010msec

Vultr （ KVM ，稳定）：

read : io=12970MB, bw=110670KB/s, iops=27667, runt=120008msec
write: io=12966MB, bw=110632KB/s, iops=27658, runt=120008msec

HostHatch(OpenVZ ，看输出的时候，非常不稳定，不过肯定是 SSD 盘子的母鸡，看到他飙过数值，但是不能长期作为生产环境使用，曾经被坑过):

read : io=1467.4MB, bw=12521KB/s, iops=3130, runt=120005msec
write: io=1464.8MB, bw=12498KB/s, iops=3124, runt=120005msec

整体性能测试（需要跑很久 UnixBench 5.1.2 ）：

Linode 2048 （ XEN ）:

System Benchmarks Index Score 459.6
System Benchmarks Index Score 881.4

DigitcalOcean 2048:

System Benchmarks Index Score 889.2
System Benchmarks Index Score 1534.7

腾讯云：

System Benchmarks Index Score 1103.5

Linode 2048 变成 KVM 之后：

System Benchmarks Index Score 1321.2
System Benchmarks Index Score 2159.7

家里的机器（ i7 4790 ， 16GM 内存， SSHD 的跑分）：

System Benchmarks Index Score 2502.6
System Benchmarks Index Score 7047.5

Linode 4096 KVM ：

System Benchmarks Index Score 3065.0

Vultr.com 2048:

System Benchmarks Index Score 1119.0
System Benchmarks Index Score 2232.7

ConoHa 2048 ：

System Benchmarks Index Score 1408.3
System Benchmarks Index Score 3402.9

HostHatch HongKong 4#(2G OpenVZ)

System Benchmarks Index Score 890.9
System Benchmarks Index Score 2164.1

UCloud (4G XenX)

System Benchmarks Index Score 1167.3
System Benchmarks Index Score 2436.7

QingCloud.cn(4G 虚拟技术未知，但是分数差到家了)

System Benchmarks Index Score 894.9
System Benchmarks Index Score 1489.4

18vps.com(2G XenX)

System Benchmarks Index Score 310.4
System Benchmarks Index Score 775.2

UClound(4G 2cpu ssd) 和一般的主机相当，可能就是多了 ssd 硬盘

System Benchmarks Index Score 1392.5
System Benchmarks Index Score 2454.4

StarryDNS.com (2G KVM)

System Benchmarks Index Score 643.7
System Benchmarks Index Score 1163.9