SMB 転送スループットがなぜこんなに低いのでしょうか?

SMB 転送スループットがなぜこんなに低いのでしょうか?

さて、タイトルが示唆するよりも少しだけ物語の内容が残っています。

背景と環境: 古い Ubuntu サーバーから新しい Windows 2012 サーバーに SMB 経由で数 TB をコピーしています。(技術的にはコモディティ ハードウェアですが、ここではサーバーです。) 全員がギガビット LAN 上にあり、古い Ubuntu ボックスには結合インターフェイスがあります。Ubuntu サーバーには 2 枚の Rosewill PCI-e 1x イーサネット カードがあり、Windows サーバーには 1 枚のかなり優れた PCI Intel イーサネット カードがあると思います。

宛先コンピュータ (Windows サーバー) は、4 台の 2TB ドライブでパリティ付きのストレージ プールを実行しています。Microsoft の新しい ReFS を実行しています。ソース コンピュータ (Ubuntu サーバー) は、ソフトウェア RAID ミラーを実行しています。古き良き EXT4 を実行しています。

2 台のサーバーは単一のギガビット スイッチを介して実行されています。ソース (Ubuntu) コンピューターの結合を解除する実験をしましたが、改善はありませんでした。

問題: 他のコンピューターから Windows サーバーに適切な速度で転送するのに問題はありません。他のコンピューターは 50 ~ 80 MB/秒を問題なく保持できますが、Ubuntu サーバーからの転送は最大でも 20 MB/秒です。4 TB 以上を 20 MB/秒で転送するには長い時間がかかります (2.3 日ほど)。ボトルネックがどこにあるかを把握するにはどうすればよいか考えています。

症状: 両方のコンピューターの CPU はごくわずかで、決して極端に忙しいわけではありません。両方のコンピューターのハード ドライブはアクティブですが、過負荷状態ではなく、少なくとも Ubuntu サーバーでは CPU IOwait はほぼ 0% です。

Wireshark トレースを 35 秒間 (おそらく、すべての ACK が新しいパケットに対するものであることを確認するのに十分な時間) 実行したところ、予想外のことがいくつかあることに気付きました。(1) Windows から Ubuntu への ACK (および一部の SMB パケット) にチェックサムがありませんでした。ただし、Wireshark によると、これは「IP チェックサム オフロード」が原因である可能性があります。わかりました。かなり良いカードが入っています。ネットワーク カードがチェックサム計算を実行できる可能性はあると思います。わかりました。次に進みましょう... (2) 「TCP が未確認セグメントに ACK しました」。これは問題があります。私が知る限り、ACK 数は許容範囲内であり、これらのメッセージの大きなブロックが頻繁にあります。Wireshark が遅すぎるだけでしょうか?

まとめ: 転送速度が悪く (ギガビット イーサネットで 20MB/秒)、その理由がわかりません。Wireshark は、Windows が Ubuntu から送信されていないものを ACK していると主張します。

推測: 私の最初の推測は、安価な Rosewill カードが過負荷になっているということです。2 番目の推測は、どちらかの端にあるソフトウェア RAID のようなものが、処理すべきことで過負荷になっているということです。

答え1

パフォーマンスのギャップは、Samba (これがまだデフォルトかどうかは不明ですが、長い間そうでした) がデフォルトの読み取りおよび書き込みソケット バッファ サイズ 1024 バイトで構成されている場合によく見られる現象と一致します。

以前は Linux や Mac マシンでこれを頻繁に見ていました。 おそらく、まだそうなっていないでしょう。

Samba の設定ファイルにはソケット オプション引数があり、読み取りおよび書き込みソケット バッファ サイズを設定できます。両方とも 8192 バイト (8 KiB) に設定することをお勧めします。4 KB または 8 KB はよく似ていますが、ギガビット リンクではテストしていません。

また、単一の TCP 接続が結合リンクの恩恵を受けるとは期待しないでください。トラフィックはほぼ常にリンクの 1 つを通過します。そうしないと、大量の順序が乱れたパケットを処理することになります。したがって、複数のクライアントにサービスを提供する場合にのみ、負荷分散の恩恵を受けることができます。その場合でも、さまざまな結合モードを調べて、少なくとも「モード 4」(IEEE 802.3ad) 結合では、基本的に 2 つの送信ハッシュ モードがあり、どのスレーブ インターフェイスに送信するかを決定することを知っておく必要があります。レイヤー 2 ハッシュ (デフォルト) とレイヤー 3 ハッシュがあります。ゲートウェイ経由で大量のデータを送信する場合、ゲートウェイの MAC アドレスが同じになるため、レイヤー 2 ハッシュは適切に分散されません。代わりにレイヤー 3 の使用を検討してください。

答え2

かつて、1 台の Ubuntu コンピューターに 2 枚のイーサネット カードが搭載されていたのですが、何らかの理由で正常に動作しませんでした。どうやら、両方とも同じパケットを奪い合っているようで、もう一方のネットワーク カードがパケットを奪取したかどうかによって、応答が返ってくることもあれば、返ってこないこともありました。奇妙な状況でした。何らかの設定ミスがあったに違いありませんが、正常に動作するだろうと思っていました。もちろん、カードには固有の IP アドレスがありました。

いずれにせよ、それを除外するために、ネットワークに接続されたマシンに 1 枚のイーサネット カードだけを入れて試してみるのは簡単です。

関連情報