解決策 1:
ファイル数と SSH 暗号化のオーバーヘッドが最大の障壁となる可能性があります。このような転送ではワイヤ スピードは見られません。
改善するオプションは次のとおりです。
- 低コストの暗号化アルゴリズムで rsync+SSH を使用する (例:
-e "ssh -c arcfour") - HPN-SSH などを使用して、SSH トランスポート上の暗号化を完全に排除する。
- ブロックベースの転送。スナップショット、
dd、ZFS スナップショットの送受信など - これが 1 回限りまたはまれな転送の場合は、
tarを使用します 、netcat (nc)、mbuffer、またはその組み合わせ。 - CentOS
tuned-admを確認してください - ファイル システム マウントから atime を削除します。他のファイル システム マウント オプションを調べています。
- NIC 送受信バッファ
rsyncのチューニング 指図。-Wだろう 、whole-files オプションはここで意味がありますか?圧縮は有効になっていますか?- 転送のタイプ (SSD、スピンドル数、RAID コントローラ キャッシュ) に合わせてストレージ サブシステムを最適化します。
解決策 2:
おそらくご存じのとおり、大量の小さなファイル (たとえば、MailDir 形式などを使用するメールボックス) をコピーすることは、帯域幅の広いインターフェイスを利用するための最良の選択肢ではありません.セカンダリ ホストに送信する前に、ソース ホストで tarball を作成します。
tar c /var/mail | ssh [email protected] 'tar x -C /var/backups'
増分バックアップが必要な場合は、-g を試してください。 それでもスループットを最大化する必要がある場合は、ssh の代わりに netcat を使用してみてください。