![针对 iSCSI/NFS 性能非常差的故障排除策略](https://linux22.com/image/582039/%E9%92%88%E5%AF%B9%20iSCSI%2FNFS%20%E6%80%A7%E8%83%BD%E9%9D%9E%E5%B8%B8%E5%B7%AE%E7%9A%84%E6%95%85%E9%9A%9C%E6%8E%92%E9%99%A4%E7%AD%96%E7%95%A5.png)
我们有一个新的 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 设备,因此不知道如何调整它来修复发现的问题。