大きなファイルをネットワーク経由でコピーするとパフォーマンスが低下する（scp）
Linuxサーバーをファイルサーバーとして使用しています。私は毎月のcronジョブを使用して、データドライブのコンテンツをtarにしてから、安全に保管するためにscpを介して別のマシンにコピーしています。結果のtarballのサイズは約300GBで、通常、コピーを完了するには（802.11g Wi-Fi接続経由で）約1日半かかります。
今日、バックアップジョブがまだ完了しておらず、3日間実行されていることに気付きました。宛先マシンを確認すると、これまでにコピーされたデータは約3分の1であり、300 KB /秒未満の速度で増加しているように見えます。
2つのマシン間でiperfを使用すると、ネットワークスループットが約20メガビット/秒であり、これは802.11g接続で期待されるものです。
ソースマシンでdd if=srcfile of=/dev/nullを使用すると、ソースドライブ（外部USBドライブ）から約45MB /秒を読み取ることができます。
宛先マシンでdd if=/dev/zero of=/destdrive/tmp.datを使用すると、宛先ドライブ（内部SATAドライブ）に約30MB /秒を書き込むことができます。 SATAドライブの場合は少し遅いようですが、不当に遅いわけではありません（300KB /秒ではありません）。
だから私は両端でネットワークスループットとドライブスループットを除外しているようです、それでボトルネックの原因を見つけるためにどこで探すことができますか？
最初に大きなファイルをコピーするためにscpを使用する理由は何ですか？ scpには独自のオーバーヘッドがあります（暗号化、信頼性チェックなど）。
rsyncを使用できます（rsyncは、何らかの理由で中断された転送を続行できるため、sshを介した大きなファイルの転送に非常に適しています。ハッシュ関数を使用して等しいファイルブロックを検出するため、続行機能は非常に堅牢です。）または他のツール。
この投稿をご覧ください。 ネットワーク経由で大きなファイルをコピーする、より高速
とにかくscpを使用する場合は、tracerouteとtcpdumpとiftopを使用して、送信元から宛先へのパケットを確認する必要があります。何か珍しいものを見つけたかもしれません。
帯域幅を制限する-lオプションが有効になっていないことを確認してください。また、-vがあると、次の実行で何が行われているのかがわかります。
冗長モード。 scpとssh（1）に、進行状況に関するデバッグメッセージを出力させます。これは、接続、認証、および構成の問題のデバッグに役立ちます。
これは以前に回答されています。答えから引用してください。
scpは、その洗練された進行状況バーを印刷するために、インタラクティブターミナルを使用しています。その出力をファイルに出力してもまったく意味がありません。そのため、scpはその出力が端末以外のどこかにリダイレクトされたことを検出し、この出力を無効にします。
完全な答え
https://stackoverflow.com/questions/3890809/bash-stdout-redirect-of-commands-like-scp
SCPのマニュアルページ
また、ファイルを10MiB/sではなく、150-300KiB/sで処理しているときに、SCPのパフォーマンスが低下しました。また、ファイルをコピーしている間、ターゲットサーバー1のCPUコアが100％ビジーであることに気付きました。私は少しググってみました proposal ：SCP接続オプションで「接続バッファーサイズの最適化」を無効にします。それは役に立ちました。このオプションを無効にすると、予想されるネットワークレベルまで速度が向上し、サーバーのCPU負荷が大幅に減少しました。