解決策 1:
理由には、圧縮、暗号化、コピーされるファイルの数とサイズ、ソース システムと宛先システムのディスク I/O 機能、TCP オーバーヘッドなどがあります。これらはすべて、実行する転送のタイプに影響を与える可能性のある要因です。
使用している rsync コマンドを投稿し、両方のコンピューターの仕様の詳細を提供してください。
編集:暗号化は、多くの場合、rsync 速度の制限要因です。 ssh と arcfour のような軽量の暗号化暗号で実行できます
次のようなもの:rsync -e "ssh -c arcfour"
または、暗号化を無効にできる変更された rsync/ssh を使用できます。 hpn-ssh を参照してください:http://psc.edu/networking/projects/hpn-ssh
ただし、繰り返しになりますが、ラップトップはワークステーションに比べてドライブが低速です。書き込みがブロックされ、ラップトップへの I/O を待機している可能性があります。あなたの本当のパフォーマンスの期待は何ですか?
解決策 2:
高い CPU 使用率を軽減しながら rsync の機能を維持するもう 1 つの方法は、rsync/SSH から rsync/NFS に移行することです。コピー元のパスを NFS 経由でエクスポートし、rsync をローカルで NFS マウントから目的の場所に使用できます。
WD MyBook Live ネットワーク ディスクからの 1 つのテストでは、ギガビット ネットワーク上の NAS から 2 つのローカル USB ディスクへの 1 つまたは複数の rsync は、エクスポート後、10MB/秒 (CPU:80% usr、20% sys) を超えてコピーされませんでした。 NFS 共有と NFS 共有から両方のディスクへのローカルでの rsyncing 合計 45MB/秒 (両方の USB2 ディスクを最大化) で、CPU 使用率はほとんどありませんでした。 rsync/SSH を使用した場合のディスク使用率は約 6% で、rsync/NFS を使用した場合は 24% 近くになりましたが、どちらの USB2 ディスクも 100% 近くでした.
そのため、ボトルネックを NAS CPU から両方の USB2 ディスクに効果的に移動させました。
解決策 3:
いくつかのテストの後、私は最終的に自分で答えを見つけました。 rsync デフォルトで ssh 経由のトンネリングを使用します。暗号はそれを遅くします。そのため、その仮想通貨を回避する必要がありました.
解決策 1:rsync サーバーをセットアップする
rsync 経由で使用するには プロトコルを使用するには、rsyncd サーバーをセットアップする必要があります。 /etc/init.d/rsync がありました ラップトップでスクリプトを実行していたので、おそらく rsyncd が実行されていました。私は間違っていた。 /etc/init.d/rsync start /etc/default/rsync で rsync が有効になっていない場合、サイレントに存在します .次に、 /etc/rsyncd.conf で構成する必要もあります 、これは苦痛です。
これがすべて完了したら、 rsync file.foo [email protected]::directory を使用する必要があります . 2 つのコロンがあることに注意してください .
解決策 2:昔ながらの rsh サーバー
しかし、構成は私には複雑すぎました。だから私はインストールして rsh-server 私のラップトップで。ワークステーションで -e rexec を使用して rsync を呼び出す 次に、ssh の代わりに rsh を使用します。これにより、パフォーマンスがほぼ 2 倍の 44.6 MB/s になりました 、まだ遅いです。速度は 58 MB/s の間で跳ね返ります および 33 MB/秒 これは、バッファまたは輻輳制御の問題がある可能性があることを示しています。しかし、それはこの質問の範囲を超えています.
解決策 4:
これらは非常に古い質問と回答ですが、重要なことが 1 つ欠けています:既に圧縮または暗号化されたデータをコピーする場合は、圧縮をオフにしてください。
データが圧縮も暗号化もされていない場合でも、一度だけ圧縮する必要があります! Rsync は -z で圧縮し、ssh は -C で圧縮します (デフォルトである可能性があります)。データが圧縮されているため、どちらが優れているかはテストしていません。
X 転送と TTY の割り当てをオフにすると、次のようになります。
rsync -avh -e "ssh -x -T -c arcfour -o Compression=no" $src $dst
最後に、確認してください (たとえば iptraf を使用) ) 使用していると思われるネットワーク インターフェイスを実際に使用していることを確認します。私のOSXでは、発信sshが、パケットがルーティングされるはずのインターフェイスのIPではなく、デフォルトの発信インターフェイスのIPにバインドされていたことに非常に驚いています。 WiFi で接続されている 2 台のラップトップ間の直接 GB クロスコネクトは使用されていませんでした。調査の結果、原因は Mac がすべてのインターフェイスに配置する 169.254/16 を使用していることと、ARP 要求が別のインターフェイスで受信されたにもかかわらず、宛先コンピューターが ARP 要求に応答したことが原因でした。