☰

为什么 vSphere ESXi 5.5 中的 Linux VM 会显示磁盘 i/o 延迟急剧增加？

tag-icon • tag-icon performance vmware-esxi storage centos6 vmware-vsphere
为什么 vSphere ESXi 5.5 中的 Linux VM 会显示磁盘 i/o 延迟急剧增加？

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

硬件：新款 Dell T110 II，双核 Pentium G850 2.9 GHz，板载 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 交互。

在继续之前，我想检查一下配置是否更合理。我在虚拟机的 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 知识库 2011861，我将 Linux i/o 调度程序更改为“ noop”而不是默认的。 cat /sys/block/sda/queue/scheduler显示它已生效。但是，我看不出它对此行为有任何影响。

在 vSphere 界面中绘制磁盘延迟，显示磁盘延迟较高的时期达到 1.2-1.5秒dd在报告吞吐量低的时候。（是的，当这种情况发生时，事情会变得非常迟钝。）

这可能是什么原因造成的？

我很确定这不是磁盘故障导致的，因为我还在同一系统中将另外两个磁盘配置为附加卷。起初我以为我对该卷做了一些错误操作，但在从 /etc/fstab 中注释掉该卷并重新启动，并尝试对 / 进行如上所示的测试后，很明显问题出在其他地方。这可能是 ESXi 配置问题，但我对 ESXi 不是很熟悉。这可能是一些愚蠢的事情，但在尝试了好几天的几个小时后，我还是找不到问题所在，所以我希望有人能给我指出正确的方向。

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

附录#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产生影响的结果。我尝试将配置文件更改为、和，保持其他所有内容不变，每次更改后重新启动，然后每次运行。这并没有影响行为：就像以前一样，一切开始正常，多次重复运行显示相同的性能，但在10-40次运行后的某个时间点，性能下降了一半。接下来，我使用了。这些结果更为广泛，因此我将它们作为下面的附录#6 放入其中。ddvirtual-guestlatency-performancethroughput-performancedd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=directddiozone

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

以下是我的总结。

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

不同的tuned配置文件似乎并没有影响（在我承认不够专业的眼睛里）广阔报告的行为iozone，但配置文件确实影响了某些细节。首先，不出所料，一些配置文件改变了写入非常大的文件时性能下降的阈值：绘制结果iozone，您可以看到配置文件在 0.5 GB 时出现陡峭的悬崖latency-performance，但配置文件下的这种下降在 1 GB 时就表现出来了enterprise-storage。其次，虽然所有配置文件在小文件大小和小记录大小的组合中都表现出奇怪的变化，但配置文件之间变化的确切模式不同。换句话说，在下面显示的图中，左侧的崎岖模式存在于所有配置文件中，但不同配置文件中凹坑的位置和深度不同。（但是，我没有重复运行相同的配置文件来查看在iozone同一配置文件下运行的变化模式是否发生明显变化，因此它是可能的各个资料之间看似存在的差异实际上只是随机变化而已。

以下是概况的不同iozone测试的表面图。测试描述是从 的文档中复制而来的。tunedlatency-performanceiozone

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

在此处输入图片描述

编写测试：该测试衡量写入新文件的性能。

在此处输入图片描述

随机阅读：该测试衡量读取文件并访问文件内随机位置的性能。

在此处输入图片描述

随机写入：该测试衡量在访问文件内随机位置的情况下写入文件的性能。

在此处输入图片描述

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

在此处输入图片描述

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

在此处输入图片描述

最后，在执行此操作期间iozone，我还在 vSphere 5 的客户端界面中检查了虚拟机的性能图。我在虚拟磁盘和数据存储区的实时图之间来回切换。数据存储区的可用绘图参数大于虚拟磁盘的绘图参数，数据存储区性能图似乎反映了磁盘和虚拟磁盘图的运行情况，因此我在此仅附上iozone完成后拍摄的数据存储区图的快照（在tuned配置文件下latency-performance）。颜色有点难以辨认，但最值得注意的是读延迟（例如，在 4:25，然后在 4:30 稍后再次出现，并在 4:50-4:55 之间再次出现）。注意：嵌入此处时，图表不可读，因此我还将其上传到http://cl.ly/image/0w2m1z2T1z2b

vSphere 虚拟机实时图表

我必须承认，我不知道该如何解释这一切。我尤其不明白这些iozone地块的小记录/小文件大小区域中奇怪的坑洼轮廓。

答案1

您能给出确切的 ESXi 版本号吗？请使用专用磁盘性能分析工具（例如菲奥或者碘来获得真正的基线。使用dd对于此目的来说并不是很有成效。

总体而言，EL6 中的默认 I/O 调度程序并不是那么好。您应该考虑转向 deadline 或 noop I/O 电梯，或者更好的是，安装调整框架。

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

答案2

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

依照指示这kb 文章我更改了Disk.DiskMaxIOSize磁盘块大小。就我的情况而言4096。

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

注意：您无需重新启动 ESX/ESXi 主机或将 ESX/ESXi 主机置于维护模式即可进行此更改。

我知道这个问题很老了，但是 mhucka 在他的帖子中投入了如此多的精力和信息，所以我不得不回答。

编辑＃1：使用 4096 一天后，我切换回了旧值32767。测试 IO 和一切似乎仍然稳定。我猜想在Disk.DiskMaxIOSize设置为的普通硬盘上运行 ESXi32767会正常工作几个小时甚至几天。也许需要虚拟机的一些负载来逐渐降低性能。

我尝试调查并稍后再回来......

答案3

尝试找出存储堆栈中导致高延迟的位置：

在此处输入图片描述

来源：vSphere 中的存储性能故障排除 - 第 1 部分 - 基础知识

相关内容