いくつかの無関係な点：
80Kは多くのファイルです。
1つのディレクトリに80,000個のファイルがありますか？デフォルトでは、このような状況をうまく処理できるオペレーティングシステムやアプリはありません。あなたはたまたまrsyncでこの問題に気づきました。
rsyncのバージョンを確認してください
最新のrsyncは、大きなディレクトリを過去よりもはるかにうまく処理します。必ず最新バージョンを使用してください。
古いrsyncでさえ、高遅延リンクを介して大きなディレクトリをかなりうまく処理します...しかし、80kファイルは大きくありません...それは巨大です！
ただし、rsyncのメモリ使用量はツリー内のファイルの数に正比例します。大きなディレクトリには大量のRAMが必要です。速度が低下するのは、どちらかの側にRAMがないためです。メモリ使用量を見ながらテストを実行します。Linuxは残りのRAMをディスクキャッシュとして使用するため、RAMが不足している場合は、ディスクキャッシュが少なくなります。RAMが不足し、システムがスワップの使用を開始した場合、パフォーマンスは非常に悪くなります。
--checksumが使用されていないことを確認してください
--checksum（または-c）すべてのファイルのすべてのブロックを読み取る必要があります。おそらく、変更時間（inodeに保存されている）を読み取るだけのデフォルトの動作でうまくいくでしょう。
ジョブを小さなバッチに分割します。
Gigasyncのようなプロジェクトでは、「perlを使用してディレクトリツリーを再帰的に処理し、rsyncで転送するファイルの小さなリストを作成することにより、ワークロードを削減します」。
追加のディレクトリスキャンは大量のオーバーヘッドになりますが、それが正味の利益になる可能性があります。
この状況では、OSのデフォルトは作成されません。
Linux / FreeBSD / etcをすべてデフォルトで使用している場合、すべてのアプリケーションのパフォーマンスはひどいものになります。デフォルトでは、サイズの大きいキャッシュでRAMを浪費しないように、より小さいディレクトリを想定しています。
ファイルシステムを調整して、大きなディレクトリをより適切に処理します。大きなフォルダーサイズはIOのパフォーマンスを低下させますか？
「nameiキャッシュ」を見てください
BSDライクなオペレーティングシステムには、iノードへの名前の検索を高速化するキャッシュ（「namei」キャッシュ）があります。各ディレクトリにはnameiキャッシュがあります。小さすぎると、最適化よりも障害になります。 rsyncは各ファイルでlstat（）を実行しているため、80kファイルごとにiノードにアクセスしているため、キャッシュが消費されている可能性があります。
別のファイルシステムを検討する
XFSは、より大きなディレクトリを処理するように設計されました。単一ディレクトリ内のファイルシステムの多数のファイルを参照してください
たぶん5分があなたができる最高です。
読み取られているディスクブロックの数を計算し、ハードウェアがその数のブロックを読み取ることができる速度を計算することを検討してください。
たぶんあなたの期待が高すぎます。ファイルを変更せずにrsyncを実行するために読み取る必要があるディスクブロックの数を検討します。各サーバーはディレクトリを読み取り、ファイルごとに1つのiノードを読み取る必要があります。おそらく、80kファイルがキャッシュを爆破したため、何もキャッシュされていないと仮定しましょう。数学を簡単に保つために80kブロックだとしましょう。これは約40Mのデータで、数秒で読めるはずです。ただし、各ブロック間でディスクシークが必要な場合は、さらに時間がかかります。
したがって、約80,000個のディスクブロックを読み取る必要があります。ハードドライブはどのくらいの速さでそれを実行できますか？これはランダムなI / Oであり、長い線形読み取りではないことを考慮すると、5分は非常に優れている可能性があります。これは1 /（80000/600）、または7.5msごとに読み取られるディスクです。ハードドライブの速度は速いですか？モデルによって異なります。
同様のものに対するベンチマーク
それについて考える別の方法はこれです。ファイルが変更されていない場合ls -Llr、同じ量のディスクアクティビティを実行しますが、ファイルデータ（メタデータのみ）を読み取りません。ls -Llr実行にかかる時間は上限です。
rsync（ファイルが変更されていない状態）は、以下よりもかなり遅いですls -Llrか？その後、rsyncに使用しているオプションを改善できます。おそらく-c有効になっているか、ディレクトリとメタデータ（inodeデータ）以外のものを読み取る他のフラグがあります。
rsync（ファイルは変更されていない）はほぼ同じくらい高速ls -Llrですか？次に、rsyncをできる限り最適に調整しました。OSの調整、RAMの追加、高速ドライブの取得、ファイルシステムの変更などが必要です。
開発者と話す
80kファイルは設計が悪いだけです。このような大きなディレクトリをうまく処理できるファイルシステムとシステムツールはほとんどありません。ファイル名がabcdefg.txtである場合、abdc / abcdefg.txtに保存することを検討してください（繰り返しに注意してください）。これにより、ディレクトリが小さなディレクトリに分割されますが、コードを大幅に変更する必要はありません。
また、...データベースの使用を検討してください。ディレクトリに80k個のファイルがある場合、開発者が本当に必要なのはデータベースであるという事実を回避している可能性があります。MariaDBまたはMySQLまたはPostgreSQLは、大量のデータを保存するためのはるかに優れたオプションです。
ねえ、5分で何が悪いの？
最後に、5分は本当にひどいですか？このバックアップを1日に1回実行する場合、5分ではそれほど時間はかかりません。はい、スピードが大好きです。ただし、5分間が顧客にとって「十分」であれば、それで十分です。書面によるSLAがない場合は、ユーザーとの非公式の議論で、バックアップの所要時間を確認してください。
パフォーマンスを改善する必要がない場合、この質問をしなかったと思います。ただし、顧客が5分間で満足している場合は、勝利を宣言し、努力が必要な他のプロジェクトに進みます。
更新：いくつかの議論の後、ボトルネックはネットワークであると判断しました。giveめる前に2つのことをお勧めします:-)。
- 圧縮によりパイプからより多くの帯域幅を絞り込もうとします。ただし、圧縮にはより多くのCPUが必要であるため、CPUが過負荷になると、パフォーマンスが低下する可能性があります。
-zを使用して、または使用せずにrsyncを試してみて、圧縮の有無にかかわらずsshを構成します。4つの組み合わせすべてに時間をかけて、いずれかが他の組み合わせよりも大幅に優れているかどうかを確認します。
- ネットワークトラフィックを監視して、一時停止があるかどうかを確認します。一時停止がある場合は、その原因を見つけて最適化できます。rsyncが常に送信している場合は、本当に限界に達しています。選択肢は次のとおりです。
- より高速なネットワーク
- rsync以外の何か
- 発信元と宛先を近づけます。それができない場合、ローカルマシンにrsyncしてから実際の宛先にrsyncできますか？最初のrsync中にシステムを停止する必要がある場合、これを行うことには利点があります。