好的，由于我正在从事大量项目，因此我可以访问 3 家托管服务提供商的专用服务器。
作为一项实验和教育目的，我决定看看是否可以对每个 IO 的性能进行基准测试。
一些研究让我找到了 Bonnie++
所以我在服务器上安装了它并运行了这个简单的命令
/usr/sbin/bonnie -d /tmp/foo
不同托管服务提供商的 3 台机器都是专用机器，一台是 VPS，另外两台位于某个云平台上，例如 VMWare / Xen，使用某种集群 SAN 进行存储
这可能是一个幼稚的做法，但这是我发现的结果。
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 速度的真实表现？
如果没有的话有什么方法可以测试吗？
注意：这 3 台机器使用的是 Ubuntu 或 Debian（我认为这并不重要）
答案1
这些网站可以帮助您解释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/
首先我想解决一下这里的一些不一致之处：
您已经进行了三种不同规模的测试，但未显示任何其他系统参数，因此您的结果很难评估。（这里的 CPU 是什么？什么样的磁盘子系统？为什么运行三种不同规模的测试？为什么使用不同版本的 bonnie？您在哪些文件系统上运行？您是否对文件系统挂载选项进行了任何改进？）
了解哪些规格对您重要取决于您的应用需求：视频流需要快速读取（bonnie 输入）性能。视频录制需要快速写入（bonnie 输出）性能。等等。
以下是我通常使用的一些小窍门/技巧：
尽可能降低系统 RAM 您可以在启动时传递内核参数来执行此操作。我通常使用 mem=512MB。这可确保您的本地操作系统缓存效果对您的 IO 测试的影响最小。
使用合适的测试规模来强调 IO 我发现 5-20G 是良好的测试范围。确保结果对于各种范围都相似，然后对所有测试使用相同的规模。
不要为每个字符的测试而烦恼。
它们不能反映真实的磁盘使用情况，而且需要时间运行。（所有关于磁盘 i/o 的事情都会发生在块上，而不是字符上）如果您在 SAN 上运行，请考虑在运行测试之前将块层清零。有时分配空间时会有首次写入惩罚。如果您在运行测试之前将整个驱动器都清零，则可以肯定您没有遇到此问题。（在同一节点上运行测试的几次迭代并比较结果也有助于确定这是否是问题）
始终发布您的 bonnie 命令行以帮助其他人重复您的测试。
EC2 提示：一些人发现在 AWS EBS 上运行软件 RAID0 条带可以提高 IO 性能。