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のようなものが、やるべきことが殺到していることです。