WAN 越しの rsync が遅いときのボトルネック診断と調整
スキャン、変更判定、SSH、圧縮、ディスク、小ファイルを分けて測り、再現可能な rsync WAN テストを作ります。
rsync のジョブがなかなか終わらず、WAN の使用率も低い場合は、データを送る前の処理に時間がかかっている可能性があります。大量のファイル一覧作成や変更判定は、回線を増速しても短縮できないことがあります。
まず、転送開始までの時間と、転送が始まってからの速度を分けて測ります。大ファイル 1 個と普段のフォルダーを同じ経路で試せば、ネットワーク、SSH の CPU 負荷、ファイルシステムのどこから調べるべきかを絞れます。
ベースラインを作る
まず変更予定を確認します。
rsync -a --dry-run --itemize-changes source/ user@example.com:/data/destination/次に本テストを行います。
rsync -a --info=progress2 --stats source/ user@example.com:/data/destination/データ転送開始までの時間、検査件数と転送件数、新規送信データと既存データの再利用量（literal / matched data）、両端 CPU、読み書き、開始から完了までの実測時間を保存します。既定ではサイズと更新時刻から変更を判定し、段階的な再帰走査で転送を進めます。それでも、大量のファイルの列挙や属性確認は必要です。挙動は公式 rsync man pageで確認してください。
1. --checksum を万能設定にしない
--checksum は変更判断のため両端で内容を読み、大規模ツリーでは転送前 I/O が大きくなります。受信側が転送データを再構築時に検証する処理とは別です。内容が変わってもサイズと更新時刻が同じになり得る場合だけ、走査時間を測って使います。
2. 1 セッションと範囲を絞った一覧を使う
ファイルごとにシェルのループで rsync を起動すると、SSH、プロセス、一覧交換、WAN 待ちを繰り返します。上流が変更パスを正確に知っている場合は、並べ替えた --files-from を試せます。
rsync -a -r --files-from=changed-files.txt source/ user@example.com:/data/destination/--files-from では -a が再帰を含まないため、必要なら -r を加えます。まず --dry-run で変更予定を確認し、不完全な一覧を「全変更の発見」用途に使わないでください。
--delete-before、--delete-after、--prune-empty-dirs、--delay-updates などは完全一覧を必要とし段階的な再帰走査を無効にする場合があります。必要な意味を削らず、事前走査時間として計上します。
3. 圧縮は実データで比較する
rsync -a --stats source/ user@example.com:/data/destination/
rsync -az --stats source/ user@example.com:/data/destination/テキストは削減できても、JPEG、MP4、ZIP はほぼ圧縮済みです。両端の版により zstd、lz4、zlib の方式の選択も異なります。CPU が飽和せず、総時間が短くなる場合だけ有効にします。
4. 中断した大ファイルを保持する
rsync -a --partial --partial-dir=.rsync-partial source/ user@example.com:/data/destination/一時保存ディレクトリは信頼できない利用者が書けない場所に置き、容量と清掃を確認します。大容量ファイルの中断には有効ですが、小ファイルのメタデータ処理の負荷は減りません。--whole-file、--inplace、更新の遅延適用との組み合わせも非本番で試します。
5. --whole-file は実験として扱う
差分アルゴリズムを止め、選択ファイルを丸ごと送ります。宛先にある比較元ファイルの読み取りが遅い、ファイルの大部分が変わった、WAN に余裕がある場合は速くなる可能性があります。回線が従量制、または巨大ファイルの一部だけが変わる場合は不利です。--stats の実際に送ったバイト数（literal data） と総時間で判断します。
6. 大ファイルと小ファイルを分ける
| 結果 | 可能性 | 次のテスト |
|---|---|---|
| 大ファイルもフォルダーも遅い | WAN、SSH CPU、ディスク、速度制御 | iperf3、CPU、ローカル I/O |
| 大ファイルは速くフォルダーは遅い | 列挙、メタデータ、ファイルごとの処理 | データ転送開始時間、1 秒あたりの処理件数 |
| ローカルでもフォルダーが遅い | ファイルシステム | メタデータ IOPS、索引処理 |
| 圧縮はテキストだけ改善 | データ形式と CPU | ファイル構成別の設定 |
| 2 回目だけ速い | キャッシュ／宛先の比較元ファイル | キャッシュなしとキャッシュありを分けて報告 |
50,000 ファイルが 1 件あたり 80ms を直列に追加すれば 4,000 秒です。rsync はパイプラインするため予測値ではありませんが、ファイル数と RTT を同時に扱う理由になります。小ファイル転送の解説も参照してください。
POSIX メタデータ、選択ルール、差分更新、自動化、標準 SSH が要件で時間を満たすなら rsync を維持します。初回の大規模コピー、小ファイル中心、外部ブラウザー配布、集中管理、SSH やソフトウェア版の管理負担を減らしたい場合は別方式を比較します。
WarpSend は rsync の所有権、ハードリンク、削除の動作、オプションの互換品ではありません。同じ送受信端、経路、ファイルで別の転送方法として比較してください。
よくある質問
WAN 越しの rsync が遅いのはなぜですか？
ディレクトリ走査、ファイルごとのメタデータ、RTT、SSH の CPU、宛先書き込み、損失、不要な --checksum 事前走査が候補です。データ転送開始まで、対象件数、RTT、損失、CPU、I/O、総所要時間を分けて測ります。
rsync は大量の小ファイルに向きますか？
rsync はパイプラインと段階的な再帰走査を使いますが、各ファイルの列挙、比較、作成、メタデータ処理は残ります。WAN が空いていてもファイルシステムや遅延で制限される場合があります。
インターネット転送では圧縮すべきですか？
実データで比較します。テキスト、ログ、CSV には有効な場合がありますが、JPEG、MP4、ZIP では削減が小さく CPU だけ増えることがあります。総所要時間が改善する場合だけ残します。
--checksum を付けると安全になりますか？
これは転送前の変更判定を変え、両端でファイル内容を読むため大きな I/O を追加します。転送済みファイルの再構築検証とは別です。サイズと更新時刻が信頼できない要件に限り、事前走査を測って使います。