web-dev-qa-db-ja.com

Rsyncが非常に遅い

WindowsPCのバックアップ用にDebianサーバーをセットアップしました。私は現在、次のようなさまざまなメソッドをテストしています：rsync（WindowsでDeltacopyを使用）、[〜＃〜] smb [〜＃〜] Samba経由およびscp。現在、rsync（SSHなし、圧縮なし）とscpは、9GBのファイル転送にギガビットLAN経由で約16分かかります。ただし、SMBは数分しかかかりません。rsyncが特に遅いのはなぜですか？変更されたビットのみを転送することから、rsyncの本当の利点がどこから来るのか誤解しているかもしれません。しかし、それでも最初の遅い転送速度を説明できないと感じており、何か間違ったことをしているに違いありません。

すべてのインスタンスで、LinuxボックスのSamba共有に転送しています。

linuxsshrsyncsambascp
3
Ben

問題は、rsyncがファイルの変更時間とサイズをクイックリファレンスとして使用して、ファイルが変更されたかどうかを判断することです。ファイルが変更されたかどうかを確認するためのより詳細で正確な方法があり、rsyncもそれをサポートしていますが、ファイルの変更時間とサイズが最初に延期された場合、これらの「より詳細な」チェックはスキップされ、rsyncはファイルを想定しますが変更されたため、ファイル全体をコピーしようとします。

特に、異種環境（Windows + Linux、...）で、ローカルファイルシステムで作業していない場合（つまり、SMBマウント/共有または他のプロトコルを使用している場合）、わずかな可能性があります。変更時刻がrsyncソースとその宛先の間で正しく渡されないこと。

変更時間は、使用されているOSやネットワークプロトコルによって切り上げられるか、変更される可能性があります。そのため、ローカルファイルシステムに「正しい」が含まれている場合でも、わずかでも異なるように見えます。 "mtime）。

これが当てはまるかどうかを確認し、コマンドライン（可能な場合）や「stat」（Linux）などのユーティリティ、または絶対に必要な場合はを出力するPerl/pythonミニプログラムでテストしてください。 ）OSおよびローカルファイルシステムプロパティを介して伝播される正確な変更時間（最終的にはSambaなどのネットワークプロトコルをバイパスします）。

UNIXでの「stat」ユーティリティの出力例：

$ stat somefile.txt 
  File: `somefile.txt'
  Size: 1014        Blocks: 8          IO Block: 4096   regular file
Device: 805h/2053d  Inode: 1448800     Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2012-07-21 17:20:33.548997182 +0530
Modify: 2011-08-16 23:27:19.648480473 +0530
Change: 2011-08-16 23:27:19.648480473 +0530

Rsyncコマンドが一貫して「16分」程度かかることはあり得ません。それは意味がありません。通常、rsyncは、各実行の前後の違いが少なくなるほど速くなります。 scpのみが、コピー量に応じて、実行するたびに一定の時間がかかります。そのため、圧縮と暗号化（ssh）をすでに除外しているという事実がパフォーマンスのボトルネックになる可能性があるため、変更時間の比較で何かが起こっている可能性があると私は思います。

私は特に、SynologyNASのSambaマウントを使用してこのケースを自分で抱えていました。ただし、それがあなたにも当てはまるかどうかにかかわらず、問題の本当の原因がすぐに見つかることを願っています。

楽しんで。

0
Paxsali