web-dev-qa-db-ja.com

2台のコンピューター間で大量のデータを送信する最も速い方法は何ですか？

これは私が頻繁にいる状況です：

  • 内部に320 GBのハードドライブを備えたソースサーバーと16 GBのRAMがあります（ 正確な仕様はこちらから入手できます 、しかし、これは私が他のマシンでも頻繁に遭遇する問題であるため、「合理的な」Linuxマシンで作業することをお勧めします）
  • 数テラバイトのハードドライブ領域を持つバックアップサーバーがあります（ 正確な仕様はこちら 、上記の免責事項を参照）

ソースサーバーからターゲットサーバーに320 GBのデータを転送したい（具体的には、/dev/sda）。

  1. 2台のコンピューターは物理的に隣り合っているので、それらの間をケーブルで接続できます。
  2. 私はLANを使用していて、 新しいルーターを使用しています です。これは、ネットワーク速度が「理想的に」1000メガビットであることを意味します。
  3. セキュリティは問題ではありません。私はローカルネットワーク上にいて、ルーターを含むネットワーク上のすべてのマシンを信頼しています。
  4. （オプション）データの署名付きチェックサムは必ずしも必要ではありませんが、基本的なエラーチェック（パケットのドロップ、ドライブが読み取り不能になるなど）です。単に出力に消えるのではなく、検出されるべきです。

私はこの質問をオンラインで検索し、いくつかのコマンドをテストしました。最も頻繁に表示されるのはこれです。

ssh [email protected] 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz

このコマンドは遅すぎることが証明されています（1時間実行され、データから約80GBしか取得できませんでした）。 1GBのテストパケットで約1分22秒かかり、圧縮しない場合は2倍の速さで終了しました。転送されたファイルがソースシステムのRAM）の量よりも少ないという事実により、結果が歪んでいる可能性もあります。

さらに（これは1GBのテストピースでテストされました）、gzipコマンドとdd;を使用すると問題が発生します。結果のファイルは、ターゲットに抽出されたときに、直接パイプされた場合とは異なるチェックサムを持ちます。私はまだこれがなぜ起こっているのか理解しようとしています。

networkingbackupddfile-transfer
113
IQAndreas

サーバーは物理的に隣り合っており、コメントでそれらに物理的にアクセスできると述べたので、fastestの方法は、最初のコンピューターからハードドライブを取り出して、次に、SATA接続を介してファイルを転送します。

139
BlueRaja - Danny Pflughoeft

netcatは、セキュリティが問題にならない次のような状況に最適です。

# on destination machine, create listener on port 9999
nc -l 9999 > /path/to/outfile

# on source machine, send to destination:9999
nc destination_Host_or_ip 9999 < /dev/sda
# or dd if=/dev/sda | nc destination_Host_or_ip 9999

GNU coreutilsのddを使用している場合は、SIGUSR1をプロセスに送信すると、進行状況がstderrに出力されます。 BSD ddの場合は、SIGINFOを使用します。

pv は、コピー中の進行状況のレポートにさらに役立ちます。

# on destination
nc -l 9999 | pv > /path/to/outfile

# on source
pv /dev/sda | nc destination_Host_or_ip 9999
# or dd if=/dev/sda | pv | nc destination_Host_or_ip 9999
69
zackse

  1. Douse fast圧縮。

    • 転送メディアが何であれ、特にネットワークやUSBの場合は、読み取り、キャッシュ、書き込みのためにデータburstsを操作しますが、これらは正確には同期しません。
    • ディスクファームウェア、ディスクキャッシュ、カーネル/ RAMキャッシュに加えて、システムのCPUを何らかの方法で使用して、交換されるデータ量をburstごとに集中させることもできます。そうするべきです。
    • どの圧縮アルゴリズムでも、入力のまばらな実行を可能な限り高速に自動的に処理しますが、残りの処理をネットワークスループットで処理するものはほとんどありません。
    • lz4 は、ここでの最良のオプションです：

      LZ4は非常に高速なロスレス圧縮アルゴリズムで、コアあたり400 MB /秒の圧縮速度を提供し、マルチコアCPUで拡張可能です。また、非常に高速なデコーダーを備えており、コアあたり数GB/sの速度で、通常、マルチコアシステムではRAM速度制限に達しています。

  2. できればnotが不必要にシークします。

    • これは測定が難しい場合があります。

    • コピー元のデバイスに多くの空き領域があり、デバイスが最近ゼロにされていないが、すべてのソースファイルシステムをコピーする必要がある場合、最初に実行する価値があると考えられます。何かのようなもの：

      </dev/zero tee >empty empty1 empty2; sync; rm empty*

    • しかし、それはあなたがソースを読むべきレベルに依存します。ファイルシステムレベルで読み取ると、ファイルシステムレベルで読み取るため、通常、/dev/some_diskデバイスファイルからデバイスを最初から最後まで読み取ることが望ましい一般に、ディスクの前後や前後をシーケンシャルにシークする必要があります。したがって、読み取りコマンドは次のようになります。

      </dev/source_device lz4 | ...

    • ただし、ソースファイルシステム全体を転送しない場合、ファイルシステムレベルでの読み取りはかなり避けられないため、入力コンテンツをストリームにまとめる必要があります。その場合、paxが一般的に最良かつ最も単純なソリューションですが、mksquashfsも検討することをお勧めします。

      pax -r /source/tree[12] | lz4 | ...
mksquashfs /source/tree[12] /dev/fd/1 -comp lz4 | ...

  3. Do notsshで暗号化します。

    • 信頼できるメディアに暗号化オーバーヘッドを追加する必要はなく、sustained転送速度に深刻な悪影響を与える可能性があるため、データの読み取りにはが必要です/ twice。
    • [〜＃〜] prng [〜＃〜] は、ランダム性を維持するために、読み取りデータ、または少なくともその一部を必要とします。
    • そしてもちろん、データも転送する必要があります。
    • 暗号化オーバーヘッド自体も転送する必要があります。つまり、転送されるデータが少ないほど多くの作業が必要になりますバーストあたり。

    • そして、むしろあなたは netcat （または、私が好むように nmap プロジェクトのより能力のある ncat を使うべきです）他の場所で提案されているように、単純なネットワークコピーの場合：

      ###  on tgt machine...
nc -l 9999 > out.lz4
###  then on src machine...
... lz4 | nc tgt.local 9999
33
mikeserv

転送速度を制限する可能性のあるいくつかの制限があります。

  1. 1Gbpsパイプには固有のネットワークオーバーヘッドがあります。通常、これにより実際のスループットは900Mbps以下に低下します。次に、これが双方向トラフィックであることを覚えておく必要があり、900Mbpsを大幅に下回るはずです。

  2. 「新しいルータ」を使用している場合でも、ルータが1Gbpsをサポートしていることを確信していますか？すべての新しいルーターが1Gbpsをサポートしているわけではありません。また、エンタープライズグレードのルーターでない限り、ルーターへの追加の送信帯域幅が失われて非効率になる可能性があります。以下で見つけたものに基づいていますが、100Mbpsを超えているようです。

  3. ネットワークを共有している他のデバイスからのネットワークの混雑がある可能性があります。できると言ったように、直接接続されたケーブルを使用してみましたか？

  4. ディスクの容量IOを使用していますか？おそらく、ネットワークではなくディスクドライブによって制限されています。ほとんどの7200rpm HDDは約40MB/sしか取得しません。 raidを使用していますか？SSDを使用していますか？リモートエンドで何を使用していますか？

これがバックアップで再実行されることが予想される場合は、rsyncを使用することをお勧めします。 ssh/http/https/ftp接続を並列化するため、反対側のfilezillaなどのダウンローダーを使用して、scp、ftp（s）、またはhttpを実行することもできます。他のソリューションは単一のパイプ上にあるため、これにより帯域幅を増やすことができます。単一のパイプ/スレッドは、それがシングルスレッドであるという事実によって依然として制限されています。つまり、CPUにバインドされる可能性さえあります。

Rsyncを使用すると、ソリューションの複雑さを大幅に排除し、圧縮、権限の保持、および部分的な転送を可能にします。他にもいくつかの理由がありますが、大企業では一般的に推奨されるバックアップ方法（またはバックアップシステムを実行）です。 Commvaultは、バックアップの配信メカニズムとして、ソフトウェアの下で実際にrsyncを使用します。

与えられた80GB/hの例に基づいて、およそ177Mbps（22.2MB/s）になります。 2つのボックス間の専用のイーサネット回線でrsyncを使用すると、これを簡単に2倍にできると思います。

25
Khrystoph

これは定期的に対処します。

私たちがよく使用する2つの主な方法は次のとおりです。

  1. SATA/eSATA /スニーカーネット
  2. 直接NFSマウント、次にローカルcpまたはrsync

1つ目は、ドライブを物理的に再配置できるかどうかに依存します。これは常にそうであるとは限りません。

2番目は驚くほどうまく機能します。通常、直接NFSマウントを使用すると、1 Gbps接続を簡単に最大化できます。 scp、dd over ssh、またはこれに類似したものを使用しても、これに近い場所はありません（最大レートが不審に100mpbsに近いことがよくあります）。非常に高速なマルチコアプロセッサであっても、2つのマシンの中で最も遅いコアの1つのコアの最大暗号スループットにボトルネックが発生します。これは、暗号化されていないネットワークマウントでのフルボアcpまたはrsyncに比べるとかなり遅いです。たまにiopsの壁にぶつかって、通常の約110MB/sではなく、約53MB/sで止まることがありますが、ソースまたは宛先が実際には単一のドライブの場合、ドライブ自体の持続速度によって制限されてしまう可能性があります（実際に試してみるまでわからないランダムな理由で十分変動します）。 -まあ。

NFSは、なじみのないディストリビューションにある場合、セットアップが少し面倒な場合がありますが、一般的に言えば、パイプを可能な限り完全にいっぱいにする最も速い方法でした。前回10 Gbps以上でこれを行ったとき、接続を使い果たしたかどうか実際にはわかりませんでした。これは、コーヒーをつかむことから戻る前に転送が終了したためです。送信元と宛先の間にいくつかのネットワークデバイスがある場合、ネットワークのわずかな遅延や一時的な障害が発生する可能性がありますが、これは通常、オフィス全体で機能します（他のトラフィックが妨害している）、またはデータセンターの一端からもう1つ（内部で何らかのフィルタリング/検査が行われていない限りこの場合、すべてのベットがオフになります）。

[〜＃〜]編集[〜＃〜]

圧縮に関するおしゃべりに気づきました...接続を圧縮しないでくださいしないでください。それは暗号層と同じようにあなたを遅くします。接続を圧縮する場合、ボトルネックは常に単一コアになります（そのコアのバスの使用率が特に高くなることもありません）。あなたの状況でできる最も遅いことは、1 Gbps以上の接続で隣り合って座っている2台のコンピューター間で暗号化された圧縮チャネルを使用することです。

将来の校正

このアドバイスは2015年半ばの時点で有効です。これはほとんど確かにこれ以上の年には当てはまりません。だから、すべてを一粒の塩で取り、このタスクに定期的に直面する場合は、想像するのではなく、実際の負荷に対してさまざまな方法を試してください理論上の最適値に近い、またはWebトラフィックなどの一般的な観測された圧縮/暗号スループットレートmuchはテキスト形式（ヒント：バルク転送は通常構成されます）主に画像、オーディオ、ビデオ、データベースファイル、バイナリコード、オフィスファイル形式などで、独自の方法で既に圧縮されており、ほとんどメリットがありません。さらに別の圧縮ルーチンを実行することから、その圧縮ブロックサイズは、既に圧縮されたバイナリデータと一致しないことがほぼ保証されています...）。

SCTPのような将来の概念は、結合された接続（または内部で結合されたスペクトルによってチャネル化されたファイバー接続）が一般的で、各チャネルが他から独立したストリームを受信できる、より興味深い場所に取り入れられると思います。ストリームは並行して圧縮/暗号化できるなどです。それは素晴らしいことです！しかし、2015年の今日はそうではありません。幻想化と理論化は素晴らしいですが、ほとんどの人は、クライオチャンバーで実行されているカスタムストレージクラスターを使用せず、Watsonの回答を生成するBlue Gene/Qの内部に直接データを供給していません。それは現実ではありません。データペイロードを徹底的に分析して、圧縮が適切かどうかを判断する時間もありません。選択した方法がどれほど悪いものであるかにかかわらず、分析が完了する前に転送自体が終了します。

だが...

時間の変化と圧縮と暗号化に対する私の推奨は成り立ちません。このアドバイスが典型的なケースですぐに覆されることを本当に望んでいます。それは私の人生を容易にします。

17
zxq9

過去に使用した気の利いたツールはbbcpです。ここに見られるように： https://www.slac.stanford.edu/~abh/bbcp/ 。

参照 http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm

このツールを使用すると、転送速度が非常に速くなります。

6
DarkHeart

どういうわけか（回線/スニーカーネット/何でも）最初のパスを取得した場合、後続の転送を大幅に高速化できる特定のオプションを使用してrsyncを調べることができます。非常に良い方法は次のとおりです。

rsync -varzP sourceFiles destination

オプションは次のとおりです。詳細、アーカイブモード、再帰的、圧縮、部分的な進行

5
Hopping Bunny

典型的な状況では最速ではないのですが、コメントの元のポスターの主張をzackseの答えに追加しました

bashには特別なリダイレクト構文があります：
出力の場合：> /dev/tcp/[〜＃〜] ip [〜＃〜]/port
入力の場合：< /dev/tcp/[〜＃〜] ip [〜＃〜]/port
[〜＃〜] ip [〜＃〜]ドット付き10進IPまたはホスト名のいずれかである必要があります。 port禁止は、10進数または/etc/servicesのポート名のいずれかです。

実際の/dev/tcp/ディレクトリはありません。 bashにTCPソケットを作成するように命令し、指定された宛先に接続して、通常のファイルリダイレクトと同じことを行う（つまり、それぞれのdup2（2）を使用したソケットの標準ストリーム）。

したがって、TCP経由でソースマシンのddまたはtarから直接データをストリーミングできます。または、逆に、TCPを介してtarなどにデータを直接ストリーミングすることもできます。いずれの場合も、1つの余分なnetcatが削除されます。

Netcatに関する注意

従来のnetcatとGNU netcatの間の構文の不整合 があります。慣れ親しんだ古典的な構文を使用します。 GNU netcatの-lpを-lに置き換えます。

また、GNU netcatが-qスイッチを受け入れるかどうかもわかりません。

ディスクイメージの転送

（ザクセの答えに沿って。）
目的地：

nc -lp 9999 >disk_image

ソース：

dd if=/dev/sda >/dev/tcp/destination/9999
 

tarを使用してtar.gzアーカイブを作成する

目的地：

nc -lp 9999 >backup.tgz

ソース：

tar cz files or directories to be transferred >/dev/tcp/destination/9999

.tgzで圧縮されたアーカイブを取得するには、.tbzをbzip2に、czをcjに置き換えます。

ファイルシステムへの即時拡張を伴う転送

また、tarを使用します。
目的地：

cd backups
tar x </dev/tcp/destination/9999

ソース：

tar c files or directories to be transferred |nc -q 1 -lp 9999

-q 1がなくても機能しますが、データが終了するとnetcatがスタックします。 tarの構文と注意事項については、tar（1）を参照してください。冗長性が高い（エントロピーが低い）ファイルが多数ある場合、圧縮（例：czとxzの代わりにcとx）を行うと、試してみてくださいが、ファイルが標準的でネットワークが十分に高速である場合、それはプロセスを遅くするだけです。圧縮の詳細については、mikeservの回答を参照してください。

代替スタイル（宛先リスニングポート）

目的地：

cd backups
nc -lp 9999 |tar x

ソース：

tar c files or directories to be transferred >/dev/tcp/destination/9999
4
Incnis Mrsi

直接接続に関する提案を試して、sshなどの暗号化プロトコルを回避してください。それでもパフォーマンスのすべてのビットを引き出したい場合は、このサイトを読んでください： https://fasterdata.es.net/Host-tuning/linux/ 最適化に関するいくつかのアドバイスについてはTCPウィンドウ。

3
Brandon Xavier

予算が主な問題ではない場合は、ドライブをIntel Xeon E5 12コアの「ドライブコネクタ」に接続してみてください。このコネクタは通常非常に強力なので、現在のサーバーソフトウェアを実行することもできます。両方のサーバーから！

これはおもしろい答えのように見えるかもしれませんが、サーバー間でデータを移動する理由と、共有メモリとストレージを備えた大きなサーバーがより理にかなっているかどうかを十分に検討する必要があります。

現在の仕様については不明ですが、転送速度が遅いのは、ネットワークではなくディスク速度によって制限されている可能性がありますか？

2
user133111

私は このスクリプトを使用しますsocatパッケージが必要なことを記述しました。

ソースマシン：

tarnet -d wherefilesaretosend pass=none 12345 .

ターゲットマシン：

tarnet -d wherefilesaretogo pass=none sourceip/12345

vbufパッケージ（Debian、Ubuntu）がある場合、ファイル送信者はデータの進行状況を表示します。ファイルレシーバーは、受信したファイルを表示します。 pass =オプションは、データが公開される可能性がある（遅い）場合に使用できます。

編集：

使用 -nオプションは、CPUがボトルネックの場合に圧縮を無効にします。

2
Skaperen

NICチーミングを検討することをお勧めします。これには、並行して実行される複数のネットワーク接続の使用が含まれます。 1 Gbを超える転送が本当に必要であり、10 Gbは法外なコストであると仮定すると、NICチーミングによって提供される2 Gbはわずかなコストであり、コンピューターにすでに追加のポートがある可能性があります。

1
Byron Jones

暗号化によって速度が低下するため、sshをスキップすることを推奨する人もいます。最近のCPUは実際には1Gbで十分高速である可能性がありますが、OpenSSHには内部ウィンドウ処理の実装に関する問題があり、大幅に速度が低下する可能性があります。

これをsshで行う場合は、 HPN SSH を参照してください。ウィンドウ処理の問題を解決し、マルチスレッド暗号化を追加します。残念ながら、クライアントとサーバーの両方でsshを再構築する必要があります。

1
Dan Pritts

FWIW、私はいつもこれを使ってきました：

tar -cpf - <source path> | ssh user@destserver "cd /; tar xf -"

この方法に関することは、それがマシン間でファイル/フォルダーのアクセス許可を維持することです（同じユーザー/グループが両方に存在すると仮定）。 ）

これを2台のビジーサーバー間でテストし、216秒で約14 GB（約64 MB /秒）を管理しました。

$ date; tar -cpf - Installers | ssh elvis "cd /home/elvis/tst; tar xf -"; date
Wed Sep  9 15:23:37 EDT 2015
Wed Sep  9 15:27:13 EDT 2015

$ du -s Installers
14211072   Installers
1
ttstooge

プログラムに関係なく、私は通常、ネットワークを介した「プル」ファイルは「プッシュ」よりも高速であることを発見しました。つまり、宛先コンピューターにログインして読み取りを行う方が、ソースコンピューターにログインして書き込みを行うよりも高速です。

また、中間ドライブを使用する場合は、次の点を考慮してください。USBではなくeSATAを使用する外部ドライブを（パッケージとして、またはドッキングステーションに接続された別のドライブとして）入手します。次に、2台のコンピュータそれぞれにeSATAポート付きのカードを取り付けるか、内部SATAポートの1つを外部eSATAコネクタに接続するシンプルなアダプタケーブルを入手します。次に、ドライブをソースコンピューターに接続し、ドライブの電源を入れ、自動マウントされるまで待ちます（手動でマウントすることもできますが、これを繰り返し行う場合は、fstabファイルに挿入することもできます）。次にコピーします。内蔵ドライブと同じ速度で書き込みます。次に、ドライブをアンマウントし、電源を切り、他のコンピュータに接続し、電源を入れ、自動マウントを待って読み取ります。

1
Mike Ciaraldi

ファイルシステムフォレンジックを実行する場合を除き、ファイルシステムのダンプ/復元プログラムを使用して、FSが使用していない空き領域をコピーしないようにします。使用しているファイルシステムによっては、通常、ctimeを含むallメタデータを保持します。ただし、iノード番号は、ファイルシステム（xfs、ext4、ufs ...）によって異なります。

復元ターゲットは、ターゲットシステム上のファイルにすることができます。

パーティションテーブルを含むフルディスクイメージが必要な場合は、ディスクの最初の1Mをddパーティションテーブル/ブートローダー/ものを取得できますが、次にxfsdumpパーティションを取得できます。

私はあなたの情報ダンプから、あなたが実際にどのようなファイルシステムを持っているのかはわかりません。 BSDのufなら、ダンプ/復元プログラムがあると思います。それがZFS、IDKなら、何かがあるかもしれません。

一般に、ディスクをフルコピーするのは、回復状況以外の場合には遅すぎます。その方法で増分バックアップを行うこともできません。

1
Peter Cordes

イーサネットクロスオーバーケーブルはどうですか？ワイヤレス速度に依存する代わりに、NICの有線速度に制限されます。

これは、その種のソリューションのいくつかの例を使用した同様の質問です。

どうやら今日では典型的なイーサネットケーブルで十分でしょう。明らかにあなたのNICが良いほど、転送が速くなります。

要約すると、ネットワーク設定が必要な場合は、サブネットマスク255.255.255.0を使用してサーバーとバックアップコンピューターの静的IPを設定するだけに制限する必要があります。

幸運を！

編集：

@Khrystophは彼の答えでこれに触れました

1
user133156

ハードドライブのバイトごとのコピーではなく、バックアップのみに関心がある場合は、backupPCをお勧めします。 http://backuppc.sourceforge.net/faq/BackupPC.html 設定は少し面倒ですが、非常に速く転送されます。

約500Gのデータの最初の転送時間は約3時間でした。その後のバックアップは約20秒で行われます。

バックアップに興味はないが、同期しようとしている場合は、rsyncまたはunisonがニーズに適しています。

ハードディスクのバイトごとのコピーは、通常、バックアップの目的ではありません（インクリメンタルなし、スペース節約なし、ドライブを使用できない、「空のスペース」をバックアップする必要がある、およびガベージをバックアップする必要がある） （16 Gのスワップファイルまたは200Gのコアダンプなど）。rsync（またはbackuppcなど）を使用して、「スナップショット」を作成し、「30分前のファイルシステムの外観」に移動できます。オーバーヘッドはほとんどありません。

つまり、バイトコピーのためにバイトを本当に転送したい場合、問題はドライブからのデータの取得ではなく、転送にあります。 RAM= 400Gが不足している場合、320Gのファイル転送には非常に長い時間がかかります。暗号化されていないプロトコルを使用することはオプションですが、何があっても、そこに座っている必要があります（ネットワーク経由で）数時間待ちます。

1
coteyr

共有ストレージを持つようにシステムをセットアップすることもできます！

私はこれらが互いに隣り合っていると考えています、そしてあなたはこれを何度も繰り返す可能性が高いです...

1
user133526

OK私は、「非常に大きなパイプ」（10Gbe）が互いに「近接」している2台のコンピューターについて、この質問に答えようとしました。

ここで発生する問題は、パイプが非常に大きいため、ほとんどの圧縮がCPUでボトルネックになることです。

10GBファイルを転送するパフォーマンス（6 Gbネットワーク接続[ノード]、非圧縮データ）：

$  time bbcp 10G root@$dest_ip:/dev/null
0m16.5s 

iperf:

server: $ iperf3 -s -F /dev/null
client:
$ time iperf3 -c $dest_ip -F 10G -t 20 # -t needs to be greater than time to transfer complete file
0m13.44s
(30% cpu)

netcat (1.187 openbsd):

server: $ nc -l 1234 > /dev/null
client: $ time nc $dest_ip 1234 -q 0 < 10G 
0m13.311s
(58% cpu)

scp:

$ time /usr/local/bin/scp 10G root@$dest_ip:/dev/null
1m31.616s
scp with hpn ssh patch (scp -- hpn patch on client only, so not a good test possibly): 
1m32.707s

socat:

server:
$ socat -u TCP-LISTEN:9876,reuseaddr OPEN:/dev/null,creat,trunc
client:
$ time socat -u FILE:10G TCP:$dest_ip:9876
0m15.989s

10 Gbeの2つのボックス、少し古いバージョンのnetcat（CentOs 6.7）、10GBファイル：

nc: 0m18.706s (100% cpu, v1.84, no -q option
iperf3: 0m10.013s (100% cpu, but can go up to at least 20Gbe with 100% cpu so not sure it matters)
socat: 0m10.293s (88% cpu, possibly maxed out)

つまり、1つのインスタンスではnetcatが使用するCPUが少なく、他のインスタンスではYMMVです。

Netcatでは、 "-N -q 0"オプションがない場合、切り捨てられたファイルを転送する可能性があります。注意してください... "-w 10"のような他のオプションも切り捨てられたファイルになる可能性があります。

これらのケースのほとんどすべてで起こっているのは、ネットワークではなく、CPUが限界に達していることです。 scpは約230 MB/sで最大になり、1つのコアを100％の使用率でペギングします。

Iperf3は残念ながら 破損 ファイルを作成します。 netcatの一部のバージョンでは、ファイル全体が転送されないようで、非常に奇妙です。特にそれの古いバージョン。

「netcatへのパイプとしてのgzip」または「mbuffer」のさまざまな呪文も、gzipまたはmbufferを使用してCPUを最大化するように見えたため、そのような大きなパイプでの転送が速くなることはありませんでした。 lz4が役立つかもしれません。さらに、私が試みたgzipパイプの一部は、非常に大きな（> 4 GB）ファイルの破損した転送を引き起こしたので、そこに注意してください:)

特にレイテンシが長い場合（？）は、TCP設定を調整することもできます。ここに推奨値を記載したガイドがあります：

http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm および https://fasterdata.es.net/Host-tuning/linux/ （from別の答え）おそらくIRQ設定： https://fasterdata.es.net/Host-tuning/100g-tuning/

linodeからの提案、/ etc/sysctl.confに追加：

net.core.rmem_max = 268435456 
net.core.wmem_max = 268435456 
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_no_metrics_save = 1
net.core.default_qdisc = fq

さらに、彼らはあなたに実行を望んでいます：

 /sbin/ifconfig eth0 txqueuelen 10000

変更が害を引き起こさないことを確認するために微調整した後に再確認する価値があります。

また、ウィンドウサイズを調整する価値があるかもしれません： https://iperf.fr/iperf-doc.php#tuningtcp

ただし、低速の接続では、圧縮が確実に役立ちます。大きなパイプがある場合、非常に高速な圧縮mightは、容易に圧縮可能なデータを支援するため、試していません。

「ハードドライブの同期」の標準的な答えは、ファイルをrsyncすることです。これにより、可能な場合は転送が回避されます。

別のオプション：「並列scp」を（何らかの方法で）使用すると、より多くのコアが使用されます...

0
rogerdpack