☰

针对 iSCSI/NFS 性能非常差的故障排除策略

tag-icon • tag-icon performance nfs iscsi troubleshooting
针对 iSCSI/NFS 性能非常差的故障排除策略

我们有一个新的 Synology RS3412RPxs，它可以为三个 Windows 2008 R2 盒提供 iSCSI 目标，并为一个 OpenBSD 5.0 盒提供 NFS。

使用 ssh 登录 RS3412 并使用 dd 和各种块大小读取/写入小文件和 6GB 文件，显示出出色的磁盘 I/O 性能。

在 iSCSI/NFS 客户端上使用 dd 或 iometer，我们达到了 20Mbps（这不是笔误。20 Mbps）。我们希望更好地利用 Synology 中的多个 Gbit NIC。

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

我将尝试在 iSCSI 目标和启动器之间建立直接链接以排除交换机问题，但我还有哪些其他选择？

如果我打破了 wireshark/tcpdump，我应该寻找什么？

答案1

似乎这里有一个共同的主题，请再次查看交换机上的流量控制设置。如果交换机有以太网计数器统计信息，请查看它们并查看是否有大量以太网 PAUSE 帧。如果是，那可能就是您的问题。通常，禁用交换机上的 QOS 可以解决此问题。

答案2

这样的流量对我来说意味着各种 TCP 流量控制方法无法正常工作。我发现 Linux 内核与 Vista 之后的 Windows 版本通信时存在一些问题，并且吞吐量也类似。如果您查看一下，它们在 Wireshark 中显示得相当好。

最糟糕的可能性是 TCP 延迟确认完全中断，您将看到如下流量模式：

packet
packet
[ack]
packet
packet
[ack]

我已通过将 NIC 驱动程序更新应用于 Windows 服务器解决了该问题。某些 (broadcom) 服务器附带的智能 NIC 有时会以有趣的方式发生故障，这就是其中一种。

正常的流量模式是大量数据包后跟一个 Ack 数据包。

另一个需要注意的是长时间延迟。可疑值是 0.2 秒和 1.0 秒。这表明一方没有得到预期的结果，正在等待超时后再回复。将上述不良数据包模式与 ACK 的 200ms 延迟相结合，您将获得高达 1MB/s 的吞吐量。

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

我没有使用过这种 NAS 设备，因此不知道如何调整它来修复发现的问题。

相关内容