为什么vSphere ESXi 5.5中的Linux VM会显着增加磁盘I / O延迟？

我很难过，我希望别人会认识到这个问题的症状。

硬件：新戴尔T110 II，双核奔腾G850 2.9 GHz，板载SATA控制器，一个新的500 GB 7200 RPM有线硬盘驱动器内的盒子，其他驱动器内，但尚未安装。 没有RAID。 软件：在VMware ESXi 5.5.0（build 1746018）+ vSphere Client下新增CentOS 6.5虚拟机。 2.5 GB的RAM分配。 该磁盘是CentOS提供的设置方式，即作为LVM卷组内的一个卷，除了我跳过单独的/ home并且只有/和/ boot。 CentOS补丁，ESXi补丁，虚拟机中安装的最新VMware工具。 系统上没有用户，没有服务正在运行，磁盘上没有文件，但操作系统安装。 我正在通过vSphere Client中的VM虚拟控制台与VM进行交互。

在进一步之前，我想检查一下我是否合理地configuration了一些东西。 我在VM的shell中以root身份运行以下命令：

for i in 1 2 3 4 5 6 7 8 9 10; do dd if=/dev/zero of=/test.img bs=8k count=256k conv=fdatasync done 

也就是说，只要重复执行10次dd命令，就会导致每次打印传输速率。 结果令人不安。 它开始好：

• 将新的虚拟磁盘添加到ESX“RHEL”中的RHEL主机
• 传入文件的roundrobin
• 2012R2存储空间内存和CPU要求
• 数组可用空间要求
• RAID级别对IOPS的影响

 262144+0 records in 262144+0 records out 2147483648 bytes (2.1 GB) copied, 20.451 s, 105 MB/s 262144+0 records in 262144+0 records out 2147483648 bytes (2.1 GB) copied, 20.4202 s, 105 MB/s ... 

但在7-8之后，它会打印

 262144+0 records in 262144+0 records out 2147483648 bytes (2.1 GG) copied, 82.9779 s, 25.9 MB/s 262144+0 records in 262144+0 records out 2147483648 bytes (2.1 GB) copied, 84.0396 s, 25.6 MB/s 262144+0 records in 262144+0 records out 2147483648 bytes (2.1 GB) copied, 103.42 s, 20.8 MB/s 

如果我等了很长时间，比如说30-45分钟，再运行一次，它又会回到105 MB / s，并且在几轮（有时甚至是几个，有时甚至是10+）之后，再次25 MB / s。

基于对可能原因的初步search，特别是VMware KB 2011861 ，我将Linux I / O调度程序更改为“ noop ”而不是默认值。 cat /sys/block/sda/queue/scheduler显示它是有效的。 但是，我看不出在这个行为上有什么不同。

绘制vSphere接口中的磁盘延迟时间，会显示dd报告低吞吐量期间磁盘延迟高达1.2-1.5 秒的时间段。 （是的，事情发生的时候，事情变得非常缓慢。）

什么可能导致这个？

我很舒服，这不是由于磁盘故障，因为我也已经在同一个系统中configuration了另外两个磁盘作为额外的卷。 起初我以为我在这个卷上做了一些错误的事情，但是在从/ etc / fstab注释掉卷并重新启动之后，如上所示尝试/如上所述进行testing之后，很明显问题在于其他地方。 这可能是一个ESXiconfiguration问题，但我对ESXi不太了解。 这可能是一些愚蠢的事情，但是经过多天的研究，我找不到这个问题，所以我希望有人能指出我的方向。

（PS：是的，我知道这个硬件组合不会赢得任何速度奖作为服务器，我有理由使用这个低端硬件和运行单个虚拟机，但我认为这是除了这个问题的重点[除非这实际上是一个硬件问题]。）

附录＃1 ：阅读其他答案，例如这个让我尝试添加oflag=direct到dd 。 然而，结果的模式没有什么区别：一开始数量较高的多轮，然后下降到20-25 MB / s。 （初始绝对数量在50 MB / s的范围内）

附录2 ：添加sync ; echo 3 > /proc/sys/vm/drop_caches sync ; echo 3 > /proc/sys/vm/drop_caches进入循环没有任何区别。

附录＃3 ：为了取出更多的variables，我现在运行dd ，使得它创build的文件大于系统上的RAM数量。 新命令是dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct 。 这个版本的命令的初始吞吐量数值是〜50 MB / s。 当南下时，他们下降到20-25 MB / s。

附录＃4 ：这是iostat -d -m -x 1的输出，在另一个terminal窗口中运行，而性能是“好的”，然后再是“坏的”。 （在这种情况下，我正在运行dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct 。）首先，当事情是“好的”时， ：

当事情变得糟糕时， iostat -d -m -x 1显示：

附录＃5 ：在@ewwhite的build议下，我尝试使用不同的configuration文件tuned ，并尝试iozone 。 在本附录中，我报告了不同的tunedconfiguration文件是否对上述dd行为有影响的实验结果。 我尝试将configuration文件更改为virtual-guest ， latency-performance和throughput-performance ，保持其他条件相同，每次更改后重新启动，然后每次运行dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct 。 它并没有影响行为：和以前一样，事情开始很好，很多重复的ddperformance出相同的性能，但是在10-40次运行之后的某个时候，性能下降了一半。 接下来，我使用了iozone 。 这些结果是更广泛的，所以我把它们放在下面的附录＃6中。

附录＃6 ：在@ewwhite的build议下，我安装并使用了iozone来testing性能。 我运行它在不同的tunedconfiguration文件，并使用非常大的最大文件大小（4G）参数iozone 。 （虚拟机有2.5 GB的RAM分配，主机总共有4 GB）。这些testing运行需要相当长的时间。 FWIW，原始数据文件可在下面的链接中find。 在所有情况下，用于生成文件的命令是iozone -g 4G -Rab filename 。

• configuration文件latency-performance ：
  • 原始结果： http : //cl.ly/0o043W442W2r
  • Excel（OSX版本）电子表格与图： http : //cl.ly/2M3r0U2z3b22
• configuration文件enterprise-storage ：
  • 原始结果： http : //cl.ly/333U002p2R1n
  • Excel（OSX版本）电子表格与图： http : //cl.ly/3j0T2B1l0P46

以下是我的总结。

在某些情况下，我在上一次运行后重新启动，在其他情况下，我没有重新启动，只需在iozone后更改configuration文件后再次运行iozone 。 这似乎并没有对整体结果产生明显的影响。

对于iozone报告的广泛行为iozone ，不同的tunedconfiguration文件似乎并没有（据我iozone ，并不专业的眼光），尽pipe这些configuration文件确实影响了某些细节。 首先，毫不奇怪的是，一些configuration文件改变了写入非常大的文件的性能下降的门槛：绘制iozone结果，您可以看到0.5 GB的iozone latency-performance但是这种下降在configuration文件enterprise-storage下显示为1 GB enterprise-storage 。 其次，尽pipe所有configuration文件对于小文件大小和小logging大小的组合都performance出奇怪的变化，但configuration文件之间的精确变异模式不同。 换句话说，在下面显示的图中，左侧的崎岖图案对于所有剖面都存在，但是凹坑的位置和它们的深度在不同剖面中是不同的。 （但是，我没有重复运行相同的configuration文件，以查看在相同configuration文件下， iozone运行之间变化的模式是否明显改变，因此configuration文件之间的差异可能仅仅是随机变化。

以下是latency-performance tuned后的不同iozonetesting的曲线图。 testing的描述是从iozone的文档复制的。

阅读testing： 这个testing测量读取现有文件的性能。

写testing： 这个testing测量写一个新文件的性能。

随机读取： 该testing测量读取文件的性能，访问文件内的随机位置。

随机写入： 此testing测量写入文件的访问性能，该访问是对文件内的随机位置进行的。

Fread： 这个testing使用库函数fread（）来测量读取文件的性能。 这是执行缓冲和阻塞读取操作的库例程。 缓冲区在用户的地址空间内。 如果应用程序读取的是非常小的数据，那么fread（）的缓冲和阻塞I / Ofunction可以通过减less实际操作系统调用的次数来增强应用程序的性能，并在操作系统时增加传输的大小打电话。

Fwrite： 该testing使用库函数fwrite（）来测量写入文件的性能。 这是执行缓冲写入操作的库例程。 缓冲区在用户的地址空间内。 如果应用程序以非常小的尺寸传输进行写入，则fwrite（）的缓冲和阻塞I / Ofunction可以通过减less实际操作系统调用的数量并在操作系统时增加传输的大小来提高应用程序的性能打电话。 这个testing正在写一个新文件，所以元数据的开销也包含在测量中。

最后，在iozone做这件事情的时候，我也在vSphere 5客户端界面上检查了虚拟机的性能图表。 我在虚拟磁盘和数据存储的实时绘图之间来回切换。 数据存储的可用绘图参数大于虚拟磁盘，数据存储性能图似乎反映了磁盘和虚拟磁盘图所做的操作，因此，在此仅附上iozone完成后所iozone的数据存储图的快照（在tunedconfiguration文件latency-performance ）。 颜色有点难以辨认，但是可能最值得注意的是读取延迟中的尖峰垂直尖峰（例如，4:25，然后在4:30之后稍微再次，以及在4：50-4：55之间）。 注意：在这里embedded的情节是不可读的，所以我也上传到http://cl.ly/image/0w2m1z2T1z2b

我必须承认，我不知道要做什么。 我尤其不了解iozone地块的小logging/小文件大小区域中怪异的坑洞剖面。