超过6000的巨型帧会使Synology读取性能下降


12

简洁版本

我的家庭网络是纯千兆位,其设备均支持最大约9000字节的巨型帧。将Synology上的MTU巨型帧设置增加到6000(字节)可以提高性能(写入810Mbps和读取945Mbps)。将该值设置为7000只会破坏读取性能(将其降低到4Mbps)。写入性能保持快速。

这是出乎意料的,因为大多数巨型帧问题都没有与之相关的方向性,并且通常是全部或全无(无论交换机来自何处,数据包都会掉落)。似乎没有发生任何 IP碎片,但是TCP层真的很不高兴。是什么原因导致这种不对称/不稳定的行为,如何解决它以支持所有我的设备应该支持的完整9000字节MTU?


长版

这些是我在试图弄清楚时所编辑的笔记。

客户

Realtek PCIe GBE系列控制器RTL8167超大
帧:9KB MTU

$ netsh interface ipv4 show subinterfaces
   MTU  MediaSenseState   Bytes In  Bytes Out  Interface
------  ---------------  ---------  ---------  -------------
  9198                1   32501506   11275394  Local Area Connection

(显示9198不包括14字节的以太网标头)

$ ping -l 1500 -f 192.168.1.84

(在客户端上运行的Wireshark上观察到;所有大小都是线字节大小)
[9213,∞]不是由主机发送的(需要分段)
[9019,9212]已发送,但没有响应
[9015,9018]分段IP响应
[ 42,9014] ]未分段的IP
[ 0,41 ]?(由于eth + IP + ICMP标头= 14 + 20 + 8 = 42字节而无法生成)

路由器(交换机部分)

Asus RT-AC68U-固件3.0.0.4.378_4585
启用巨型帧:“启用”
无法弄清楚其实际支持的巨型帧大小,似乎至少为9000

它将来自客户端的ping请求分割为1514字节(但是ping路由器可能触发其WAN路由器行为而不是其LAN交换机行为?)

非托管交换机

TP-LINK TL-SG1008D超大
框架(规格表):9KB(他们的网站上说15KB,但看起来像是另一台设备)

服务器

Synology DS1815 +-DSM 5.2-5565更新1超大
帧:9000

从Synology到客户端的文件读取数据包
大小:大多数为9014字节(双向)
IP标志:不要对
Wireshark进行分段:发现TCP杂散重传,TCP未捕获上一段,TCP乱序,TCP快速重传,和常规(9014字节)数据包
SMB2-over-NetBIOS协议数据包读取响应读取长度:65,536(〜8个TCP段)

$ ifconfig
bond0     Link encap:Ethernet  HWaddr --:FF
          inet addr:192.168.1.84  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addrs: --/64 Scope:Link, --/64 Scope:Global, --/64 Scope:Global
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:85 dropped:0 overruns:0 frame:85
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:237 GiB  TX bytes:117 GiB

eth2      Link encap:Ethernet  HWaddr --:00
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:19 dropped:0 overruns:0 frame:19
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:236 GiB  TX bytes:83 GiB

eth3      Link encap:Ethernet  HWaddr --FF
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:66 dropped:0 overruns:0 frame:66
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1 GiB  TX bytes:33 GiB

eth2和eth3使用自适应负载平衡绑定(不支持开关)

$ ping -c 5 -s 1500 192.168.1.82

(在客户端上运行的Wireshark上观察到;所有大小均为电线字节大小)
[9019,∞]请求已发送,已发送响应,未接收到响应
[9015,9018]碎片IP请求(可能由Synology碎片化,busybox ping没有无碎片选项,因此很难说)
[60,9014] 无碎片IP
[ 0,59 ]?(无法生成,因为busybox ping至少放入18个字节加上42个字节的标头)

杂项数据

  • 将客户端MTU更改为8KB并没有帮助
  • 当将服务器的MTU从6000(最大,945Mbps)更改为7000(可怕,4Mbps)时,服务器的读取速度跌落
  • 服务器的写入速度基本上不受所有服务器MTU设置的影响(始终在700到825 Mbps之间)
  • Synology具有绑定网络(4个端口中的2个)
  • 电缆均为Cat6或Cat5e

您需要通过synology提交支持票。我没有任何有关Synology的经验,所以我不知道是否存在可以增加内存缓冲区大小的高级设置,但这可能是需要的。就我个人而言,我通常会得到920mbits,并且根本不使用任何巨型帧。只需使用通用的非托管式netgear交换机即可。
Cyber​​nard

Answers:


2

更新固件

以我的经验,Synology修复了每个固件版本中的许多问题,而您正在运行的版本已使用了将近四年。我还没有阅读发行说明,但是自那时以来,似乎已经有很多修复Jumbo框架错误的机会。

直接连接测试

使用新的跳线将您的测试计算机直接连接到Synology(在同一子网中分配静态IP),然后重新运行测试。这将消除布线和开关以及任何其他设备和配置问题。如果问题仍然存在,请在另一台计算机上运行测试。如果仍然存在,那肯定是NAS。

如果在直接连接测试期间问题仍然存在,请尝试先更换交换机,然后再布线。您尚未显示连接,所以我假设测试计算机和NAS之间只有TPLINK。

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.