iSCSI/NFS性能极差的故障排除策略

Question

我们有一个新的语法RS3412RPxs，它为三个Windows2008 R2盒和一个OpenBSD 5.0框提供了iSCSI目标。

使用ssh登录到RS3412，使用dd和各种块读写小文件和6GB文件，显示出很好的磁盘I/O性能。

在iSCSI/NFS客户端上使用dd或I测量仪，我们可以达到20 20Mbps (这不是一个错误)。20 Mbps)。我们希望能更好地利用语法中的多个Gbit NIC。

我已经验证了交换机和NIC端口配置设置为千兆位，而不是自动协商。我们试过有和没有Jumboframes没有区别。我已经用ping验证了MTU目前是9000。已经部署了两次固件升级。

我将尝试在iSCSI目标和发起者之间直接链接，以排除开关问题，但我的其他选项是什么？

如果我逃出wireshark/tcpdump，我要找什么？

Answer 1

就像这里常见的主题一样，再看看开关(Es)上的流控制设置。如果交换机(Es)有以太网计数器统计数据，请查看它们，看看是否有大量的以太网暂停帧。如果是的话，那可能是你的问题。通常，在交换机(Es)上禁用QOS解决了这个问题。

Answer 2

这样的流告诉我，各种TCP流控制方法都不能正常工作。我见过Linux内核在使用后Vista Windows版本时遇到了一些问题，您可以通过这样的操作。你一看，他们就会在Wireshark上表现得很好。

最糟糕的情况是TCP延迟的ack被完全破坏了，您将看到如下的流量模式：

packet
packet
[ack]
packet
packet
[ack]

我通过将NIC驱动程序更新应用到Windows服务器解决了这个问题。一些(broadcom)服务器附带的智能NIC有时会以有趣的方式失败，这就是其中之一。

正常的流量模式是大量的数据包，然后是Ack数据包。

另一个需要寻找的是长时间的拖延。可疑值为.2秒和1.0秒。这意味着一方并没有得到它预期的结果，而是在等待一个超时时间到期后才会回复。将上面的坏数据包模式与ACK的200 of延迟结合起来，您就可以获得高达1MB/s的吞吐量。

这些都是容易被注意到的不良交通模式。

我还没有使用过这种NAS设备，所以我不知道如何调整它来修复发现的任何东西。