rsyncがNFSより速いのはなぜですか？

数日前、私は（少なくとも私にとって）奇妙なことに気づきました。私はrsyncを実行して同じデータをコピーし、その後それをNFSマウント（という名前で）に削除しました/nfs_mount/TEST。これ/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です。

結論：両方の転送は、同じネットワークサブネット、同じワイヤ、同じインターフェースを経由し、同じデータを読み取り、同じディレクトリに書き込みます。違いは、NFSv3経由、rsync経由の違いのみです。

クライアントはUbuntu 10.04、サーバーUbuntu 9.10です。

どうしてrsyncの方がずっと速いのですか？NFSをその速度に合わせる方法は？

ありがとう

編集：rsyncを使用してNFS共有またはSSHに書き込み、NFSサーバーにローカルに書き込みます。どちらの場合もrsync -av、明確な宛先ディレクトリから始めます。明日は普通のコピーで試します。

Edit2（追加情報）：ファイルサイズの範囲は1KB〜15MBです。ファイルはすでに圧縮されていますが、さらに圧縮しようとしましたが成功しませんでした。それからtar.gzファイルを作成しましたdir。パターンは次のとおりです。

• 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）には問題ありませんが、チェックサムの計算と必要なファイルのリストの生成中に、1バイトが転送される前に、rsh over sshがリモートサーバーでかなりのCPUおよび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 1秒でその5MBを1MBに圧縮できます。この場合、圧縮データの送信時間は1秒をわずかに超えますが、非圧縮データは5秒です。

-e "ssh Ciphers = arcfour"も使用して、スループットを向上させます。

ある場所から別の場所にすべてのファイルをコピーするだけの場合、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のように選択することはできないため、増分バックアップなどには適していませんが、データのコピーやアーカイブには適しています。

nfsshareにファイルロック設定がありますか？無効にした場合、より多くのパフォーマンスを得ることができます。

速度の向上は、少なくとも部分的には「rsync src host：/ path」がリモートマシン上でローカルプロセスを送信/受信するために発生し、I / Oを事実上半分に削減しているためだと思います。