SMB転送スループットがこのように低いのはなぜですか？

わかりました、タイトルが意味するよりもストーリーにはもう少しあります。

背景と環境：古いUbuntuサーバーから新しいWindows 2012サーバーにSMB経由で数TBをコピーしています。（技術的には、これは一般的なハードウェアですが、このあたりのサーバーです。）誰もがギガビットLAN上にあり、古いUbuntuボックスには結合されたインターフェイスがあります。Ubuntuサーバーには2つのRosewill PCI-e 1xイーサネットカードがあり、Windowsサーバーには適切なPCI Intelイーサネットカードが1つあると思います。

移行先コンピューター（Windowsサーバー）は、4x 2TBドライブを超えるパリティーを持つストレージプールを実行しています。Microsoftの新しいReFSを実行しています。ソースコンピューター（Ubuntuサーバー）はソフトウェアRAIDミラーを実行しています。EXT4を実行しています。

2つのサーバーは、単一のギガビットスイッチを介して実行されています。私はソース（Ubuntu）コンピューターの結合を何の改善もなく壊す実験をしました。

問題：他のコンピュータからWindowsサーバーに妥当な速度で転送することに問題はありません。他のコンピューターは50〜80 MB /秒を保持することができますが、そのUbuntuサーバーからの転送は20 MB /秒を超えません。20MB / sで4 + TBは長い時間がかかり（2.3日など）、ボトルネックがどこにあるのかを突き止めるために何ができるか疑問に思っています。

症状：両方のコンピューターのCPUはかなり最小限であり、確実に非常にビジーではありません。両方のコンピューターのハードドライブはアクティブですが、圧迫されていません。CPUIOwaitは、少なくともUbuntuサーバーではほぼ0％です。

Wiresharkトレースを35秒間（おそらく、すべてのACKが新しいパケットに対するものであることを確認するのに十分な長さ）トレースしましたが、予期しないものがかなりあることに気付きました。（1）WindowsからUbuntuへのACK（および一部のSMBパケット）のチェックサムがありませんでした。ただし、Wiresharkは、これは「IPチェックサムオフロード」が原因である可能性があると主張しています。はい、かなりいいカードを入れています。ネットワークカードがチェックサム計算を実行できる可能性があると思います。いいね。次に進みます...（2）「TCP ACKing unseen segment。」これは私が問題を抱えています。ACK番号は、私がわかる範囲から許容範囲内であり、これらのメッセージの大きなブロックがしばしば存在します。おそらくWiresharkは遅すぎるのでしょうか？

要約：転送速度が悪く（ギガビットイーサネット経由で20MB /秒）、理由はわかりません。Wiresharkは、WindowsがUbuntuから送信されたことのないものにACKを送信していると主張している。

推測：私の最初の推測では、安価なRosewillカードが氾濫しているとのことです。私の2番目の推測は、一端または他端のソフトウェアRAIDのようなものが、やるべきことが殺到していることです。

Samba（これがまだデフォルトであるかどうかは不明ですが、長い間そうでした）がデフォルトの読み取りおよび書き込みソケットバッファーサイズ1024バイトで構成されている場合、パフォーマンスギャップは一般的なエクスペリエンスと一致します。

LinuxとMacマシンでこれを頻繁に見ました。うまくいけば、それはまだそのケースではありません。

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

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

私はかつて1台のUbuntuコンピュータに2枚のイーサネットカードを持っていましたが、何らかの理由で適切に機能しませんでした。両方とも、見た目と同じパケットで競合しました。満員。変だった。どういうわけかそれを誤って構成していたに違いないが、私はそれがちょうどうまくいっただろうと思っただろう。もちろん、カードには固有のIPアドレスがありました。

とにかく、それを除外するために、ネットワークに接続されたマシンの1つのイーサネットカードだけでそれを試すのは簡単です。