rsyncがNFSより速いのはなぜですか？
数日前、（少なくとも私にとっては）奇妙なことに気づきました。同じデータをコピーし、後でNFSマウント（/nfs_mount/TEST）に削除するrsyncを実行しました。この/nfs_mount/TESTはnfs_server-eth1からホスト/エクスポートされます。両方のネットワークインターフェイスのMTUは9000で、その間のスイッチはジャンボフレームもサポートしています。 rsync -av dir /nfs_mount/TEST/を実行すると、ネットワーク転送速度X MBpsが得られます。 rsync -av dir nfs_server-eth1:/nfs_mount/TEST/を実行すると、ネットワーク転送速度が少なくとも2X MBpsになります。私のNFSマウントオプションはnfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcpです。
結論：両方の転送は、同じネットワークサブネット、同じ配線、同じインターフェイスを経由し、同じデータを読み取り、同じディレクトリに書き込みます。違いは、1つだけがNFSv3経由で、もう1つがrsync経由です。
クライアントはUbuntu 10.04、サーバーはUbuntu 9.10です。
なぜrsyncの方がずっと速いのですか？ NFSをその速度に合わせる方法は？
ありがとう
編集：NFS共有への書き込みまたはNFSサーバーへのSSH接続とローカルでの書き込みにrsyncを使用していることに注意してください。どちらの場合もrsync -avを行います。最初は明確な宛先ディレクトリから始めます。明日はプレーンコピーでやってみます。
Edit2（追加情報）：ファイルサイズの範囲は1KB〜15MBです。ファイルはすでに圧縮されているので、さらに圧縮しようとしましたが、成功しませんでした。そのdirからtar.gzファイルを作成しました。ここにパターンがあります：
rsync -av dir /nfs_mount/TEST/=最も遅い転送。rsync -av dir nfs_server-eth1:/nfs_mount/TEST/=ジャンボフレームを有効にした最速のrsync。ジャンボフレームを使用しない場合は少し遅くなりますが、NFSへの直接フレームよりも大幅に高速です。rsync -av dir.tar.gz nfs_server-eth1:/nfs_mount/TEST/= tar.gz以外の同等のものとほぼ同じ。
cpおよびscpを使用したテスト：
cp -r dir /nfs_mount/TEST/=rsync -av dir /nfs_mount/TEST/よりもわずかに高速ですが、rsync -av dir nfs_server-eth1:/nfs_mount/TEST/よりも大幅に低速です。scp -r dir /nfs_mount/TEST/=全体的に最も速く、rsync -av dir nfs_server-eth1:/nfs_mount/TEST/をわずかに上回ります。scp -r dir.tar.gz /nfs_mount/TEST/= tar.gz以外の同等のものとほぼ同じ。
結論、この結果に基づく：このテストでは、tar.gzの大きなファイルを使用しても、小さなファイルを多数使用しても、大きな違いはありません。ジャンボフレームをオンまたはオフにしても、ほとんど違いはありません。 cpとscpは、対応するrsync -avの同等物より高速です。エクスポートされたNFS共有への直接書き込みは、使用する方法に関係なく、SSH経由で同じディレクトリに書き込むよりも大幅に遅くなります（少なくとも2倍）。
この場合、cpとrsyncの違いは関係ありません。私はcpとscpを試してみると、同じパターンを示し、2倍の違いがあるかどうかを確認するだけでした。
どちらの場合もrsyncまたはcpを使用しているため、NFSがSSHを介して同じコマンドの転送速度に到達できない原因を理解できません。
NFS共有への書き込みがSSH経由で同じ場所に書き込むよりも2倍遅いのはなぜですか？
Edit3（NFSサーバー/ etc/exportsオプション）：rw,no_root_squash,no_subtree_check,sync。クライアントの/ proc/mountsはnfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcpを示しています。
皆さん、ありがとうございました！
転送速度が遅くなることはないかもしれませんが、書き込みレイテンシが増加します。同期ではなくNFS共有を非同期でマウントしてみて、速度のギャップがなくなるかどうかを確認してください。 sshを介してrsyncを実行すると、リモートrsyncプロセスは非同期で（迅速に）書き込みを行います。ただし、同期的にマウントされたnfs共有に書き込む場合、書き込みはすぐには確認されません。NFSサーバーは、書き込みが成功したという確認をNFSクライアントに送信する前に、ディスク（またはコントローラーキャッシュ）にヒットするまで待機します。
「非同期」で問題が解決した場合、書き込み中にNFSサーバーで何かが発生すると、ディスク上のデータに一貫性がなくなる可能性があります。このNFSマウントがこの（またはその他の）データのプライマリストレージでない限り、おそらく問題ありません。もちろん、rsync-over-sshの実行中または実行後にnfsサーバーのプラグを抜いた場合（たとえば、rsyncが「完了」を返し、nfsサーバーがクラッシュし、書き込みキャッシュ内のコミットされていないデータが失われるようになります）一貫性のないデータをディスクに残します）。
テスト（rsyncの新しいデータ）の問題ではありませんが、sshを介したrsyncにより、CPUが大幅に増加し、チェックサムの計算中に1バイトが転送される前にリモートサーバーにIOが要求される）更新する必要のあるファイルのリストを生成します。
NFSは共有プロトコルですが、Rsyncはファイル転送用に最適化されています。 アプリオリが共有アクセスを提供する代わりにできるだけ速くファイルをコピーすることであることがわかっているときに実行できる多くの最適化がありますそれら。
これは役立つはずです http://en.wikipedia.org/wiki/Rsync
Rsyncは、ファイル間で変更されたビットのみを転送するファイルプロトコルです。 NFSはリモートディレクトリファイルプロトコルであり、毎回すべてを処理します...ある意味ではSMBのような方法です。2つは異なり、目的も異なります。Rsyncを使用して2つの間で転送できます。 NFS共有。
これは面白い。考慮していない可能性は、送信するファイルの内容/タイプです。
小さなファイルのカスケード（個々のファイルの電子メールなど）がある場合、MTU全体を使用していないため、NFSの効率が低下している可能性があります（TCP over UDPの場合） 。
または、非常に圧縮可能なファイル/データ、高速CPU、およびCPU（*）の速度があまりないネットワークがある場合、sshリンクを介した暗黙的な圧縮だけで速度を上げることができます。
3番目の可能性は、ファイル（またはその1つのバージョン）が宛先にすでに存在していることです。この場合、rsyncプロトコルによってファイルの転送が節約されるため、速度が向上します。
（*）この場合、「速度」とは、ネットワークがデータを送信できる速度と比較して、CPUがデータを圧縮できる速度を指します。 5MBを送信するのに5秒かかりますが、CPUは5MBを1秒で1MBに圧縮できます。この場合、圧縮データの送信時間は1秒をわずかに超えますが、非圧縮データは5秒です。
すべてのファイルをある場所から別の場所にコピーするだけの場合は、tar/netcatが最速のオプションになります。ファイルに多くの空白（ゼロ）があることがわかっている場合は、-iオプションを使用してください。
出典：tar cvif-/ path/to/source | nc DESTINATION PORTNUM DESTINATION：cd/path/to/source && nc -l PORTNUM | tar xvif-
データが圧縮可能であることがわかっている場合は、tarコマンドで圧縮を使用します-z -j -Ipixz
私はpixz .. parallel xzのファンです。これは優れた圧縮を提供し、ネットワーク帯域幅に合わせてCPUの数を調整できます。帯域幅が遅い場合は高い圧縮率を使用するため、ネットワークよりもCPUで待機します。高速ネットワークの場合は非常に低い圧縮率を使用します。
出典：tar cvif-/ path/to/source | pixz -2 -p12 | nc DESTINATION PORTNUM＃tar、ゼロを無視、12 CPUコアを使用したレベル2 pixz圧縮DESTINATION：nc -l PORTNUM | tar -Ipixz -xvif
圧縮レベルとコアを正しく調整すると、データセットに応じて、ネットワークを飽和状態に近づけ、ボトルネックとなっている十分な圧縮をディスクにできるはずです（通常、読み取りおよび書き込みディスクシステムの場合は書き込み側）同じ）。
rsyncに関しては、tarがそのオプションで行うのと同様に、ゼロをスキップするので、NFSよりも少ないデータを送信します。 NFSはデータに関する仮定を行うことができないため、NFSプロトコルのオーバーヘッドとともにすべてのバイトを送信する必要があります。 rsyncにはオーバーヘッドがあります。
netcatには基本的に何もありません。必要なデータだけを含む完全なTCPパケットを送信します。
netcatでは、scpと同様に、すべてのソースデータを常に送信する必要があります。rsyncのように選択することはできないため、増分バックアップやそのようなものには適していませんが、データのコピーやアーカイブには適しています。
また、-e "ssh Ciphers = arcfour"を使用してスループットを向上させています。
NFS共有にファイルロック設定がありますか？無効にすると、パフォーマンスが大幅に向上する可能性があります。