なぜ私のrsyncはとても遅いのですか？
私のラップトップとワークステーションは両方ともギガビットスイッチに接続されています。どちらもLinuxを実行しています。しかし、rsyncを使用してファイルをコピーすると、パフォーマンスが低下します。
約22 MB /秒を取得します。理論的には約125 MB/sにすべきではありませんか？ここでの制限要因は何ですか？
編集：いくつかの実験を行いました。
ノートパソコンでパフォーマンスを書きます
ラップトップには、完全なディスク暗号化を備えたxfsファイルシステムがあります。それは使用しています aes-cbc-essiv:sha256 256ビットのキー長の暗号モード。ディスク書き込みパフォーマンスは58.8 MB/sです。
iblue@nerdpol:~$ LANG=C dd if=/dev/zero of=test.img bs=1M count=1024
1073741824 Bytes (1.1 GB) copied, 18.2735 s, 58.8 MB/s
ワークステーションでパフォーマンスを読み取る
コピーしたファイルは、ソフトウェアRAID-5 over 5 HDDにあります。 raidの上にはlvmがあります。ボリューム自体は同じ暗号で暗号化されます。ワークステーションには、暗号化を高速化するネイティブAES-NI命令セットを備えたFX-8150 cpuがあります。ディスク読み取りパフォーマンスは256 MB/s（キャッシュはコールドでした）です。
iblue@raven:/mnt/bytemachine/imgs$ dd if=backup-1333796266.tar.bz2 of=/dev/null bs=1M
10213172008 bytes (10 GB) copied, 39.8882 s, 256 MB/s
ネットワーク性能
2つのクライアント間でiperfを実行しました。ネットワークパフォーマンスは939 Mbit/s
iblue@raven $ iperf -c 94.135.XXX
------------------------------------------------------------
Client connecting to 94.135.XXX, TCP port 5001
TCP window size: 23.2 KByte (default)
------------------------------------------------------------
[ 3] local 94.135.XXX port 59385 connected with 94.135.YYY port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.09 GBytes 939 Mbits/sec
高いCPU使用率を軽減しながらrsyncの機能を維持する別の方法は、rsync/SSHからrsync/NFSに移行することです。 NFS経由でコピーするパスをエクスポートし、NFSマウントから宛先の場所にローカルでrsyncを使用できます。
WD MyBook Liveネットワークディスクからの1つのテストでは、NASから2つのローカルUSBディスクに向けた1つ以上のrsyncは、10MB /秒を超えてコピーしません（CPU：80％usr 、20％sys）、NFSを介してローカルにエクスポートし、NFS共有から両方のディスクにrsyncした後、合計45MB /秒（両方のUSB2ディスクを最大化）でCPU使用率はほとんどありませんでした。rsync/ SSHを使用した場合のディスク使用率は約6でした％およびrsync/NFSの使用は24％近くでしたが、両方のUSB2ディスクは100％近くでした。
したがって、ボトルネックをNAS CPUから両方のUSB2ディスクに効果的に移動しました。
理由には、圧縮、暗号化、コピーされるファイルの数とサイズ、コピー元とコピー先のシステムのディスク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がラップトップに送信されるのを待機している可能性があります。あなたの実際のパフォーマンスの期待は何ですか？
さらにテストを行った後、ようやく自分で答えを見つけました。 rsyncはデフォルトでssh経由のトンネリングを使用します。暗号はそれを遅くします。だから私はその暗号のものを回避する必要がありました。
解決策1：rsyncサーバーのセットアップ
rsyncプロトコル経由で使用するには、rsyncdサーバーを設定する必要があります。ラップトップに/etc/init.d/rsyncスクリプトがあったので、rsyncdが実行されていたと思います。私は間違っていた。 /etc/init.d/rsync startでrsyncが有効になっていない場合、/etc/default/rsyncはサイレントモードで存在します。次に、/etc/rsyncd.confでも構成する必要がありますが、これは面倒です。
これをすべて完了したら、rsync file.foo user@machine::directoryを使用する必要があります。 2つのコロンがあることに注意してください。
解決策2：古い学校のrsh-server
ただし、構成が複雑すぎて私にはわかりませんでした。ラップトップにrsh-serverをインストールしました。ワークステーションで-e rexecを使用してrsyncを呼び出すと、sshではなくrshが使用されます。これにより、パフォーマンスがほぼ2倍になります44.6 MB/s、これはまだ遅いです。速度は58 MB/sと33 MB/sの間で跳ねます、これは、バッファまたは輻輳制御の問題があることを示しています。しかし、それはこの質問の範囲を超えています。
これらは非常に古い質問と回答ですが、重要なことが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要求に応答したことが原因でした。