好的，由于我正在进行一系列的项目，我可以访问3个托pipe服务提供商的专用服务器。
作为一个实验，为了教育的目的，我决定看看我是否可以用IO来衡量IO的好坏。
研究的一点点导致我到Bonnie ++
所以我把它安装在服务器上，运行这个简单的命令
/usr/sbin/bonnie -d /tmp/foo 不同托pipe服务提供商中的3台机器都是专用机器，一台是VPS，另外两台是在某个云平台上，例如使用某种集群SAN进行存储的VMWare / Xen
这可能是一个天真的事情，但这里是我发现的结果。
HOST A Version 1.03c ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP xxxxxxxxxxxxxxxx 1G 45081 88 56244 14 19167 4 20965 40 67110 6 67.2 0 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 15264 28 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ xxxxxxxx,1G,45081,88,56244,14,19167,4,20965,40,67110,6,67.2,0,16,15264,28,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++ HOST B Version 1.03d ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP xxxxxxxxxxxx 4G 43070 91 64510 15 19092 0 29276 47 39169 0 448.2 0 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 24799 52 +++++ +++ +++++ +++ 25443 54 +++++ +++ +++++ +++ xxxxxxx,4G,43070,91,64510,15,19092,0,29276,47,39169,0,448.2,0,16,24799,52,+++++,+++,+++++,+++,25443,54,+++++,+++,+++++,+++ HOST C Version 1.03c ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP xxxxxxxxxxxxx 1536M 15598 22 85698 13 258969 20 16194 22 723655 21 +++++ +++ ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 14142 22 +++++ +++ 18621 22 13544 22 +++++ +++ 17363 21 xxxxxxxx,1536M,15598,22,85698,13,258969,20,16194,22,723655,21,+++++,+++,16,14142,22,+++++,+++,18621,22,13544,22,+++++,+++,17363,21
那么，首先，阅读数字的最佳方法是什么？在比较这些数字时是否存在任何问题？
这是否以任何方式真正代表IO Speed？
如果没有，我有什么办法来testing？
注意：这3台机器使用Ubuntu或Debian（我认为这并不重要）
这些网站可以帮助您解读bonnie结果：
http://www.textuality.com/bonnie/advice.html
http://www.issociate.de/board/post/478953/Understanding_bonnie++_results.html
http://sourceforge.net/projects/witme/files/bonnie-to-chart/
首先，我想在这里解决一些不一致的地方：
你已经完成了三种不同的testing大小，并没有显示任何其他的系统参数，所以你的结果很难评估。 （这里是什么CPU？什么types的磁盘子系统？你为什么运行三种不同的大小？为什么你使用不同版本的bonnie？你在运行什么文件系统？你在做什么文件系统挂载选项的改进？
了解什么样的规格取决于您的应用需求：videostream需要快速读取（bonnieinput）性能。 video录制需要快速写入（bonnie输出）性能。 等等
以下是我经常使用的一些邦妮技巧/窍门：
尽可能降低系统RAM您可以在启动时传递内核参数来执行此操作。 mem = 512MB是我通常使用的。 这确保您的本地操作系统caching效果对IOtesting的影响最小。
使用一个体面的testing大小压力IO我觉得5-20G是很好的testing范围。 确保你的结果是相似的各种或范围，然后使用相同的大小进行所有的testing。
不要打扰每个字符testing。
它们不反映真实世界的磁盘使用情况，需要时间来运行。 （只是所有关于磁盘I / O将发生与块，而不是字符）
如果您在SAN上运行，请考虑在运行testing之前将您的块层调零。 有时在分配空间时会有第一次写入的惩罚。 如果你在运行testing之前把你的整个驱动器取出来，你可以肯定地知道你没有碰到这个。 （在同一节点上运行多次testing并比较结果也可以帮助识别这是否是一个问题）
总是发布你的bonnie命令行来帮助其他人复制你的testing。
EC2提示：有几个人在AWS EBS上发现运行软件RAID0条带来提高IO性能。