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

Question

我很难过，我希望其他人能认识到这个问题的症状。

硬件：新的戴尔 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 已修补，VM 中安装了最新的 VMware 工具。系统上没有用户，没有运行的服务，磁盘上没有文件，只有操作系统安装。我通过 vSphere Client 中的 VM 虚拟控制台与 VM 交互。

在继续之前，我想检查一下我是否或多或少地合理配置了一些东西。我在 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

即，只需重复 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 GB 处enterprise-storage. 其次，尽管所有配置文件对于小文件大小和小记录大小的组合都表现出奇怪的可变性，但不同配置文件之间的精确可变性模式不​​同。换句话说，在下图所示的图中，所有剖面都存在左侧的崎岖图案，但不同剖面的凹坑位置和深度不同。（但是，我没有重复运行相同的配置文件，以查看在同一配置文件iozone下运行之间的变异模式是否发生显着变化，因此配置文件之间的差异可能实际上只是随机变异。）

以下是iozone的tuned轮廓的不同测试的曲面图latency-performance。测试的描述是从iozone.

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

写测试：这个测试衡量写新文件的性能。

随机读取：此测试测量读取文件的性能，并访问文件中的随机位置。

随机写入：此测试测量写入文件时对文件内随机位置进行访问的性能。

Fread：该测试测量使用库函数 fread() 读取文件的性能。这是一个执行缓冲和阻塞读取操作的库例程。缓冲区位于用户的地址空间内。如果应用程序要读取非常小的传输大小，那么 fread() 的缓冲和阻塞 I/O 功能可以通过减少实际操作系统调用的数量并增加操作系统时的传输大小来提高应用程序的性能调用。

Fwrite：该测试测量使用库函数 fwrite() 写入文件的性能。这是一个执行缓冲写操作的库例程。缓冲区位于用户的地址空间内。如果应用程序要写入非常小的传输大小，那么 fwrite() 的缓冲和阻塞 I/O 功能可以通过减少实际操作系统调用的数量并增加操作系统时的传输大小来提高应用程序的性能调用。此测试正在写入一个新文件，因此元数据的开销再次包含在测量中。

最后，在此期间iozone，我还检查了 vSphere 5 客户端界面中虚拟机的性能图。我在虚拟磁盘和数据存储的实时图之间来回切换。数据存储的可用绘图参数大于虚拟磁盘的绘图参数，并且数据存储性能图似乎反映了磁盘和虚拟磁盘图正在做什么，所以在这里我只附上了iozone完成后拍摄的数据存储图的快照（在tuned配置文件下）latency-performance）。颜色有点难以阅读，但也许最值得注意的是阅读中的尖锐垂直尖峰延迟（例如，在 4:25，然后在 4:30 之后再次，以及在 4:50-4:55 之间再次）。注意：当嵌入这里时，情节是不可读的，所以我也把它上传到了http://cl.ly/image/0w2m1z2T1z2b

我必须承认，我不知道如何看待这一切。我特别不明白iozone地块的小记录/小文件大小区域中奇怪的坑洼轮廓。

Answer 1

您能给出确切的 ESXi 内部版本号吗？请使用专门构建的磁盘性能分析工具（例如fio或iozone）再次尝试测试，以获得真正的基线。使用dd这个并没有真正的生产力。

一般来说，EL6 中默认的 I/O 调度器并不是那么好。您应该考虑转移到截止日期或 noop I/O 电梯，或者更好的是，安装调整后的框架。

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