web-dev-qa-db-ja.com

Synologyの読み取りパフォーマンスが6000以上のジャンボフレームで低下する

短縮版

私のホームネットワークは、すべてが少なくとも9000バイトまでのジャンボフレームをサポートするデバイスを備えた純粋なギガビットです。 SynologyのMTUジャンボフレーム設定を6000（バイト）に増やすと、パフォーマンスが向上します（書き込み810Mbps、読み取り945Mbps）。値を7000に設定すると、読み取りパフォーマンスのみが破壊されます（これにより、4Mbpsまでずっと低下します）。書き込みパフォーマンスは高速のままです。

ほとんどのジャンボフレームの問題には方向性が関連付けられておらず、通常はすべてか何もないため（パケットがどこから来たかに関係なく、スイッチでドロップされます）、これは予期せぬことです。 any 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 Out-Of-順序、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によっておそらくフラグメント化されています。busyboxpingにはフラグメント化されていないオプションがないため、わかりにくいです）
[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です。
ethernetthroughput
12
colithium

ファームウェアを更新する

私の経験では、Synologyは各ファームウェアリリースの多くの問題を修正し、実行しているものは4年近く前のものです。私はリリースノートを読んでいませんが、ジャンボフレームのバグが修正される機会はたくさんあるようです。

直接接続でテストする

新しいパッチケーブルを使用してテストマシンをSynologyに直接接続し（同じサブネットに静的IPを割り当て）、テストを再実行します。これにより、ケーブル配線やスイッチ、その他の機器や構成の問題がなくなります。問題が解決しない場合は、別のコンピューターでテストを実行します。それがまだ残っている場合、それは確かにNASです。

直接接続テスト中に問題が解消した場合は、まずスイッチを交換してから、ケーブルを交換してください。接続を表示していないので、テストマシンとNASの間のTPLINKのみを想定しています。

2
Jens Ehrich