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

我很沮丧，希望其他人能认识到此问题的症状。

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

在继续之前，我想检查一下我是否或多或少合理地配置了东西。我以root用户身份在VM的shell中运行以下命令：

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

即，只需重复dd命令10次，这将导致每次打印传输速率。结果令人不安。它很好地开始了：

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+），它下降到了约20-再次为25 MB / s。

基于对可能原因的初步搜索，尤其是VMware KB 2011861，我将Linux i / o调度程序更改为“ noop”，而不是默认值。 cat /sys/block/sda/queue/scheduler表明它是有效的。但是，我看不到它对这种行为有什么影响。

在vSphere界面中绘制磁盘延迟，可以显示在报告低吞吐量的过程中磁盘延迟较高的时间达到1.2-1.5 秒dd。（是的，在这种情况下，事情变得毫无反应。）

是什么原因造成的？

我很高兴这不是由于磁盘故障引起的，因为在同一系统中我还配置了另外两个磁盘作为附加卷。起初，我以为该卷有问题，但是在从/ etc / fstab中注释掉该卷并重启后，如上所示尝试对/进行测试之后，很明显问题出在其他地方。这可能是ESXi配置问题，但是我对ESXi的经验不是很丰富。这可能是愚蠢的，但是经过数天的反复尝试，我仍然找不到问题所在，因此希望有人能指出正确的方向。

（PS：是的，我知道此硬件组合不能作为服务器获得任何速度奖，而且我有使用这种低端硬件并运行单个VM的理由，但我认为这不是该问题的重点[除非实际上是硬件问题]。）

附录1：阅读其他答案（例如此答案）使我尝试添加oflag=direct到dd。但是，结果的模式没有什么不同：最初，许多回合中的数字更高，然后降至20-25 MB / s。（初始绝对数字在50 MB / s的范围内。）

附录2：添加sync ; echo 3 > /proc/sys/vm/drop_caches到循环中完全没有区别。

附录3：要取出更多变量，我现在运行dd，以使其创建的文件大于系统上的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在性能为“良好”时在另一个终端窗口中运行的输出，然后在性能为“不良”时再次运行。（虽然这种情况一直在发生，但我正在运行dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct。）首先，当事情“良好”时，它显示如下：

当事情变得“不好”时，iostat -d -m -x 1显示如下：

附录5：在@ewwhite的建议下，我尝试使用tuned其他配置文件，也尝试使用iozone。在此附录中，我报告了不同的tuned配置文件是否对上述dd行为有任何影响的实验结果。我尝试将配置文件更改为virtual-guest，latency-performance并throughput-performance保持其他所有设置不变，每次更改后重新启动，然后每次运行dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct。它并没有影响行为：像以前一样，事情开始时还不错，许多重复的运行dd显示出相同的性能，但是在10-40次运行之后的某个时候，性能下降了一半。接下来，我用iozone。这些结果更为广泛，因此我将其作为下面的附录6列出。

附录6：在@ewwhite的建议下，我安装并用来iozone测试性能。我在不同的tuned配置文件下运行它，并使用了很大的最大文件大小（4G）参数iozone。（VM分配了2.5 GB的RAM，主机总共分配了4 GB。）这些测试运行花费了很长时间。FWIW，原始数据文件在下面的链接中可用。在所有情况下，用于生成文件的命令为iozone -g 4G -Rab filename。

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

以下是我的总结。

在某些情况下，我在上次运行后重新启动，而在其他情况下却没有，iozone在使用更改配置文件后再次运行tuned。这似乎并未对总体结果产生明显的影响。

尽管个人资料确实影响了某些细节，但不同的tuned个人资料似乎（似乎对我不熟练的专家而言）似乎不会影响所报告的广泛行为iozone。首先，毫不奇怪，某些配置文件更改了写入超大文件的性能下降的阈值：绘制iozone结果，您可以看到配置文件在0.5 GB处出现了陡峭的悬崖，latency-performance但在配置文件下该下降量显示为1 GBenterprise-storage。其次，尽管对于小文件大小和小记录大小的组合，所有配置文件都表现出怪异的可变性，但在不同的配置文件之间，可变性的精确模式有所不同。换句话说，在下面显示的图中，所有轮廓都存在左侧的凹凸图案，但凹坑的位置及其深度在不同轮廓中是不同的。（不过，我没有相同的配置文件重复运行，看是否变异的模式明显的运行之间的变化iozone相同的配置下，因此可能是什么样子的配置文件之间的差异其实只是随机变化）。

以下是不同iozone测试的表面tuned轮廓图latency-performance。测试说明是从的文档中复制的iozone。

读取测试：此测试衡量读取现有文件的性能。

写入测试：此测试用于衡量写入新文件的性能。

随机读取：此测试通过对文件中的随机位置进行访问来衡量读取文件的性能。

随机写入：此测试通过访问文件中的随机位置来测量写入文件的性能。

Fread：此测试使用库函数fread（）来衡量读取文件的性能。这是一个库例程，执行缓冲和阻止的读取操作。缓冲区在用户的地址空间内。如果应用程序要读取很小的传输大小，则fread（）的缓冲和阻塞I / O功能可以通过减少实际的操作系统调用次数和增加操作系统传输的大小来增强应用程序的性能。打电话了。

Fwrite：此测试衡量使用库函数fwrite（）写入文件的性能。这是一个执行缓冲写操作的库例程。缓冲区在用户的地址空间内。如果应用程序要以很小的传输量进行写入，则fwrite（）的缓冲和阻塞I / O功能可以通过减少实际的操作系统调用次数并增加操作系统时的传输量来提高应用程序的性能。打电话了。此测试正在写入新文件，因此再次将元数据的开销包括在测量中。

最终，在完成任务期间iozone，我还检查了vSphere 5客户端界面中VM的性能图。我在虚拟磁盘和数据存储的实时图之间来回切换。数据存储区的可用绘图参数大于虚拟磁盘的数据，并且数据存储区性能图似乎反映了磁盘和虚拟磁盘图的工作，因此在此，我仅附上iozone完成后拍摄的数据存储区图的快照（在tuned配置文件下）。latency-performance）。颜色有点难以阅读，但也许最值得注意的是阅读中的垂直尖峰等待时间（例如，在4:25，然后在4:30之后再稍稍，然后在4：50-4：55之间再一次）。注意：该图在此处嵌入时不可读，因此我也将其上传到了http://cl.ly/image/0w2m1z2T1z2b

我必须承认，我不知道该怎么做。我特别不了解iozone绘图的小记录/小文件大小区域中怪异的坑洞轮廓。

您能否提供确切的ESXi内部版本号？请使用专用磁盘性能分析工具（如fio或iozone）再次尝试测试，以获得真实的基准。使用此操作dd实际上没有效果。

通常，EL6中的默认I / O调度程序不是那么好。您应该考虑转移到截止日期或不使用I / O电梯，或者更好的是安装调整后的框架。

尝试：yum install tuned tuned-utils和tuned-adm profile virtual-guest，然后再次测试。

我遇到了同样的问题，并注意到虚拟机中的驱动器性能非常慢。我在Seagate ST33000650NS上使用ESXi 5.5。

通过阅读这篇 kb文章，我更改Disk.DiskMaxIOSize为磁盘块大小。就我而言4096。

VMware对此的说明非常好，因为您可以对其进行测试。

注意：可以进行此更改，而无需重新引导ESX / ESXi主机或不将ESX / ESXi主机置于维护模式。

我知道这个问题很老，但是穆卡（Mhucka）在他的帖子中投入了太多精力和信息，我不得不回答。

编辑＃1：在使用4096天之后，我切换回旧值32767。测试IO，一切似乎仍然稳定。我的猜测是，在Disk.DiskMaxIOSize设置为的普通HDD上运行ESXi可以正常32767工作几个小时甚至几天。也许需要VM承担一些负载才能逐渐降低性能。

我尝试进行调查，稍后再回来...

尝试找出导致存储延迟高的地方：

来源：在vSphere中对存储性能进行故障排除–第1部分–基础