解决ESXi NFS数据存储上的延迟峰值问题

44

我在ESXi中的NFS数据存储上遇到了大约五秒钟的 fsync延迟，这是由某些VM触发的。我怀疑这可能是由使用NCQ / TCQ的VM引起的，因为在虚拟IDE驱动器中不会发生这种情况。

可以使用fsync-tester（由Ted Ts'o）和ioping复制。例如，使用带有8GB磁盘的Grml实时系统：

Linux 2.6.33-grml64:
root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 5.0391
fsync time: 5.0438
fsync time: 5.0300
fsync time: 0.0231
fsync time: 0.0243
fsync time: 5.0382
fsync time: 5.0400
[... goes on like this ...]

那是5秒，而不是毫秒。甚至在同一主机和数据存储上运行的不同VM上创建IO延迟：

root@grml /mnt/sda/ioping-0.5 # ./ioping -i 0.3 -p 20 .
4096 bytes from . (reiserfs /dev/sda): request=1 time=7.2 ms
4096 bytes from . (reiserfs /dev/sda): request=2 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=3 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=4 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=5 time=4809.0 ms
4096 bytes from . (reiserfs /dev/sda): request=6 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=7 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=8 time=1.1 ms
4096 bytes from . (reiserfs /dev/sda): request=9 time=1.3 ms
4096 bytes from . (reiserfs /dev/sda): request=10 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=11 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=12 time=4950.0 ms

当我将第一个VM移到本地存储时，它看起来非常正常：

root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 0.0191
fsync time: 0.0201
fsync time: 0.0203
fsync time: 0.0206
fsync time: 0.0192
fsync time: 0.0231
fsync time: 0.0201
[... tried that for one hour: no spike ...]

我尝试过的事情没有什么区别：

  • 测试了多个ESXi版本：381591、348481、260247
  • 在不同的硬件，不同的Intel和AMD盒上进行了测试
  • 在不同的NFS服务器上进行测试，都显示出相同的行为：
    • OpenIndiana b147（始终或禁用ZFS同步：没有区别）
    • OpenIndiana b148（始终或禁用ZFS同步：没有区别）
    • Linux 2.6.32（同步或异步：没有区别）
    • NFS服务器是在同一台计算机上（作为虚拟存储设备）还是在另一台主机上，这没有什么区别

来宾OS经过测试，显示问题：

  • Windows 7 64位（使用CrystalDiskMark，延迟峰值通常发生在准备阶段）
  • Linux 2.6.32（fsync-tester + ioping）
  • Linux 2.6.38（fsync-tester + ioping）

我无法在Linux 2.6.18 VM上重现此问题。

另一个解决方法是使用虚拟IDE磁盘（相对于SCSI / SAS），但这会限制性能和每个VM的驱动器数量。

更新2011-06-30：

如果应用程序在fsync之前写入多个小块，则延迟峰值似乎更经常发生。例如，fsync-tester执行此操作（strace输出）：

pwrite(3, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 1048576, 0) = 1048576
fsync(3)                                = 0

ioping在准备文件时会这样做：

[lots of pwrites]
pwrite(3, "********************************"..., 4096, 1036288) = 4096
pwrite(3, "********************************"..., 4096, 1040384) = 4096
pwrite(3, "********************************"..., 4096, 1044480) = 4096
fsync(3)                                = 0

ioping的设置阶段几乎总是挂起，而fsync-tester有时可以正常工作。有人能够更新fsync-tester来编写多个小块吗？我的C技能很烂;）

更新2011-07-02：

iSCSI不会发生此问题。我在OpenIndiana COMSTAR iSCSI服务器上尝试了此操作。但是iSCSI无法让您轻松访问VMDK文件，因此您可以在具有快照和rsync的主机之间移动它们。

更新2011-07-06：

这是Wireshark捕获的一部分，该捕获由同一vSwitch上的第三个VM捕获。所有这些都发生在同一主机上，不涉及物理网络。

我已经在20左右开始ioping。直到五秒钟的延迟结束，才发送任何数据包：

No.  Time        Source                Destination           Protocol Info
1082 16.164096   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1085), FH:0x3eb56466 Offset:0 Len:84 FILE_SYNC
1083 16.164112   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1086), FH:0x3eb56f66 Offset:0 Len:84 FILE_SYNC
1084 16.166060   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet-locate [ACK] Seq=445 Ack=1057 Win=32806 Len=0 TSV=432016 TSER=769110
1085 16.167678   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1082) Len:84 FILE_SYNC
1086 16.168280   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1083) Len:84 FILE_SYNC
1087 16.168417   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1057 Ack=773 Win=4163 Len=0 TSV=769110 TSER=432016
1088 23.163028   192.168.250.10        192.168.250.20        NFS      V3 GETATTR Call (Reply In 1089), FH:0x0bb04963
1089 23.164541   192.168.250.20        192.168.250.10        NFS      V3 GETATTR Reply (Call In 1088)  Directory mode:0777 uid:0 gid:0
1090 23.274252   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1185 Ack=889 Win=4163 Len=0 TSV=769821 TSER=432716
1091 24.924188   192.168.250.10        192.168.250.20        RPC      Continuation
1092 24.924210   192.168.250.10        192.168.250.20        RPC      Continuation
1093 24.924216   192.168.250.10        192.168.250.20        RPC      Continuation
1094 24.924225   192.168.250.10        192.168.250.20        RPC      Continuation
1095 24.924555   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet_svinfo [ACK] Seq=6893 Ack=1118613 Win=32625 Len=0 TSV=432892 TSER=769986
1096 24.924626   192.168.250.10        192.168.250.20        RPC      Continuation
1097 24.924635   192.168.250.10        192.168.250.20        RPC      Continuation
1098 24.924643   192.168.250.10        192.168.250.20        RPC      Continuation
1099 24.924649   192.168.250.10        192.168.250.20        RPC      Continuation
1100 24.924653   192.168.250.10        192.168.250.20        RPC      Continuation

第二次更新2011-07-06：

TCP窗口大小似乎有一些影响。使用FreeNAS（基于FreeBSD）作为NFS服务器，我无法重现此问题。Wireshark捕获显示TCP窗口定期更新为29127字节。我没有在OpenIndiana上看到它们，默认情况下使用更大的窗口大小。

如果我在OpenIndiana中设置以下选项并重新启动NFS服务器，我将不再重现此问题：

ndd -set /dev/tcp tcp_recv_hiwat 8192 # default is 128000
ndd -set /dev/tcp tcp_max_buf 1048575 # default is 1048576

但这会降低性能：从/ dev / zero到dd_rescue的文件写入速度从170MB / s变为80MB / s。

更新2011-07-07：

我已经上传了这个tcpdump捕获（可以使用Wireshark分析）。在这种情况下，192.168.250.2是NFS服务器（OpenIndiana b148），而192.168.250.10是ESXi主机。

我在此捕获期间测试过的东西：

开始“ ioping -w 5 -i 0.2”。在时间30暂停5秒，在时间40完成。

开始“ ioping -w 5 -i 0.2”。在时间60，设置已挂起5秒钟，并在时间70结束。

在时间90开始“ fsync-tester”，输出如下，在时间120停止：

fsync time: 0.0248
fsync time: 5.0197
fsync time: 5.0287
fsync time: 5.0242
fsync time: 5.0225
fsync time: 0.0209

第二次更新2011-07-07：

测试了另一个NFS服务器VM，这次是NexentaStor 3.0.5社区版：显示相同的问题。

更新2011-07-31：

我还可以在新的ESXi内部版本4.1.0.433742上重现此问题。

vmware-esxi  nfs  latency 
— exo_cw
source
12
我不得不说，自从一个崭新的用户来到董事会以来，就已经有一段时间了，它有一个经过充分记录和深思熟虑的问题-认真的说，对您表示敬意。这也真的很有趣，我之前也没有遇到过fsync-tester，所以谢谢。也就是说，我不确定是否要添加任何东西，您已经尝试了很多本来可以做的事情-老实说，我想跟VMWare谈一谈，他们非常擅长采用这种方法“长尾巴” /“不是实际的服务中断”的问题。无论如何，只是想说您到目前为止已做的很好：)
— Chopper3 2011年
不幸的是，VMware网站不允许我与他们联系：“您目前没有有效的支持权利”
— exo_cw 2011年
啊，是的，那当然是个问题……
— Chopper3 2011年
3
NFS的5秒超时听起来很熟悉。在linux NFS中，RPC的超时时间为0.7秒，在每次失败后会翻倍，在3次失败后会拉大调（默认设置）。.7 + 1.4 + 2.8 = 4.9秒。各种各样的RPC身份验证问题都可能导致此问题。
— 标记
2
@Ryan：我已经上传了捕获文件。我还上传了nfsstat输出。
— exo_cw 2011年

Answers:

5

此问题似乎已在ESXi 5中修复。我已经成功测试了内部版本469512。

— exo_cw
source
3

谢谢，nfsstat看起来不错。我已经审查了捕获的内容。尚无定论，但确实找到了一些有趣的东西。我筛选了tcp.time_delta>5。在每个延迟实例中发现的是RPC调用的确切开始。并非所有新的RPC调用都变慢，但是所有减速都发生在RPC调用的确切开始时。另外，从捕获中可以看出，192.168.250.10包含所有延迟。192.168.250.2立即响应所有请求。

发现：

  • 延迟总是发生在RPC调用的第一个数据包中
  • NFS命令类型与延迟实例无关
  • 碎片=仅延迟第一个数据包

一个大的Write Call可以分解为300个单独的TCP数据包，只有第一个数据包被延迟，其余的全部通过。延迟永远不会在中间发生。我不确定窗口大小如何严重影响连接的开始。

后续步骤：我将开始向下调整NFS选项（例如NFSSVC_MAXBLKSIZE），而不是TCP窗口。另外，我注意到2.6.18有效，而2.6.38无效。我知道在该时间段内已添加了对VMXnet3驱动程序的支持。您在主机上使用哪些NIC驱动程序？TCP卸载是/否？在95秒标记附近，单个NFS写调用有500多个TCP数据包。无论负责TCP还是分解大型PDU都可能成为阻碍。

— 瑞安
source
我尝试将nfs：nfs3_max_transfer_size，nfs：nfs3_max_transfer_size_cots和nfs：nfs3_bsize都设置为8192：没有区别，同样的问题。linux guest虚拟机仅使用其SCSI / SAS磁盘，没有NFS-ESXi是NFS客户端，因此linux guest虚拟机上没有网络驱动程序问题。在NFS服务器端，我已经尝试了虚拟e1000和vmxnet3：没有区别。据我所知，ESXi仅将TCP卸载用于iSCSI。
— exo_cw 2011年
最大的 ？我有一个原因，为什么调整TCP窗口会有所作为...我的直觉告诉我，这与通过TCP分割那些较大的PDU有关。网络堆栈中令人窒息的东西。只是想不出任何适合我们所看到的行为的东西。如果窗口大小是一个问题，我们应该在大型传输的中间看到延迟限制带宽，而不是开始，但是它始终是RPC调用的第一个数据包……很难。
— 瑞安
2

使用ESXi4.1U1和CentOS VM时，我遇到了同样的问题。主机是Dell R610，存储是EMC2 Isilon群集。

您是否有机会使用VLAN？我发现在VMkernel端口上使用VLAN进行存储会导致VMHost上的所有存储流量“挂起” 4000-5000ms。但是，如果我将VMkernel端口移出VLAN，以便它接收未标记的数据包，则不会出现此问题。

下面的简单设置将导致我的网络出现问题：

1）在服务器或工作站上安装ESXi 4.1U1（我尝试都出现了问题）

2）在VLAN上添加VMkernel端口。

3）添加一个NFS数据存储（我的存储在同一VLAN上，即Isilon接收标记的数据包）

4）安装2个CentOS 5.5 VM，其中一个带有ioping。

5）将VM引导到单用户模式（即无网络，最低服务）

6）在一台机器上运行ioping以便将其写入虚拟磁盘

7）在另一台机器上运行dd或类似的东西以将100MB数据写入/ tmp或类似文件

我经常看到两个VM冻结4-5秒。

真的很感兴趣，看看是否有人看过类似的东西。

— 缺口
source
欢迎来到服务器故障！这是一个老问题。如果答案不能直接帮助您，则应通过单击“ 提问”按钮询问新的新问题。
— user9517支持GoFundMonica 2011年
是的，我当然使用标记的VLAN。当我到处使用它们时，我什至没有想到它们是此问题的潜在根源。我将尝试在未标记的端口上重现此内容。
— exo_cw 2011年
我也可以在未标记的端口上重现此问题，该主机上根本不涉及任何VLAN。
— exo_cw 2011年
我只是再次尝试，并且在未标记的端口上也看到了该问题，它的出现频率有所降低，这也许就是我错过它的原因。对不起，转向。我无法使用iometer在Win7 64位上看到问题，而且看来我可以浏览c：驱动器，而其他linux虚拟机却挂了。我将尝试使用crystaldiskmark
— Nick
实际上，我很想在win7 x64上使用iometer查看您的结果。它测量延迟，但是使用4k读取测试，我得到的最高总体数字是300ms，而不是4000 + ms
— Nick
2

两周前，我们遇到了完全相同的问题。ESX41 U1和Netapp FAS3170 + NFS数据存储。RHEL5 VM挂起2或4秒钟，我们发现Virtual Center性能控制台的峰值很高。

我请网络人员检查配置，问题出在cisco交换机上。我们有两个以太网链路是在Netapp端而不是cisco端的Etherchannel上配置的。他在cisco上创建了一个静态的Ethechannel，现在可以正常工作了。要确定这种问题，请关闭除文件管理器和交换机之间的端口以外的所有端口。保持一个端口处于活动状态，看看情况如何。

我们要做的第二件事是删除switcj和文件管理器上的流控制，因为我们怀疑它发送了暂停帧。

— 劳伦特
source
1

您的DNS看起来如何？你说的对/etc/resolv.conf吗 默认超时为5秒。

从 man resolv.conf

timeout:n
                 sets the amount of time the  resolver  will  wait  for  a
                 response  from  a  remote name server before retrying the
                 query via a different name server.  Measured in  seconds,
                 the default is RES_TIMEOUT (currently 5, see <resolv.h>).

尝试附加timeout:3到/etc/resolv.conf，然后再次运行fsync测试。

— 约瑟夫·科恩
source
我尝试将其添加到NFS服务器（在这种情况下为OpenIndiana）和ESXi主机上。不幸的是，这并没有改变。我可以解析服务器和来宾IP。
— exo_cw 2011年
看起来您过滤掉了与nfs流无关的所有流量，我们可能需要了解更多信息！
— 托尼·罗斯
@tony roth：实际上那是当时的全部流量。我在单独的vSwitch上进行了测试，其中仅包含主机和NFS服务器。
— exo_cw 2011年
可以通过Wireshark转储DNS吗？
— Joseph Kern
@Joseph Kern：我刚刚再次分析了捕获文件：捕获过程中根本没有DNS流量。NFS数据存储区通过IP映射到ESXi主机上。DNS在ESXi和NFS服务器上运行良好，我测试了所有涉及IP的正向和反向查找。现在，我没有理由相信DNS是造成这种情况的原因。
— exo_cw 2011年
1

在这里，您可以使用吸管，但是在这些服务器中使用的是什么NIC？Stack Overflow系统管理员在使用Broadcom NIC时遇到了怪异的网络问题，当他们切换到Intel NIC时这些问题消失了：http : //blog.serverfault.com/post/broadcom-die-mutha/

— 邮编
source
最后的测试仅在vSwitch上完成，不涉及任何物理网络（e1000和vmxnet3：无差异）。但是我也在Intel 82574L，Intel 82576和Intel 82567LF-3上进行了测试，都显示出了问题。我没有找到任何无法重现此硬件的硬件。
— exo_cw 2011年
1

这是另一个猜测... EXS主机上是否启用了IPv6？如果是，请尝试将其关闭？根据我的经验，如果您的整个网络未正确配置为IPv6（即RADV，DHCP6，DNS，反向DNS），则某些服务可能会出现问题。另外，请确保在NFS服务器上将其关闭。

— 杜贝利斯
source
ESXi主机上已禁用IPv6。我已在NFS服务器上禁用了IPv6（ifconfig -a6现在为空），但没有任何区别：它显示了相同的问题。
— exo_cw 2011年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.