Mengapa rsync lebih cepat dari NFS?

Beberapa hari yang lalu saya melihat sesuatu yang agak aneh (setidaknya untuk saya). Saya menjalankan rsync menyalin data yang sama dan menghapusnya kemudian ke NFS mount, dipanggil /nfs_mount/TEST. Ini /nfs_mount/TESTdihosting / diekspor dari nfs_server-eth1. MTU pada kedua antarmuka jaringan adalah 9000, pergantian di antara mendukung bingkai jumbo juga. Jika saya melakukannya, rsync -av dir /nfs_mount/TEST/saya mendapatkan kecepatan transfer jaringan X MBps. Jika saya melakukannya, rsync -av dir nfs_server-eth1:/nfs_mount/TEST/saya mendapatkan kecepatan transfer jaringan minimal 2X MBps. Opsi pemasangan NFS saya adalah 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.

Intinya: kedua transfer melewati subnet jaringan yang sama, kabel yang sama, antarmuka yang sama, membaca data yang sama, menulis ke direktori yang sama, dll. Satu-satunya perbedaan adalah melalui NFSv3, yang lain melalui rsync.

Klien adalah Ubuntu 10,04, server Ubuntu 9,10.

Kenapa rsync jauh lebih cepat? Bagaimana membuat NFS cocok dengan kecepatan itu?

Terima kasih

Sunting: harap dicatat saya menggunakan rsync untuk menulis ke share NFS atau ke SSH ke server NFS dan menulis secara lokal di sana. Kedua kali saya lakukan rsync -av, mulai dengan direktori tujuan yang jelas. Besok saya akan coba dengan salinan biasa.

Edit2 (info tambahan): Ukuran file berkisar dari 1KB-15MB. File-file sudah dikompresi, saya mencoba kompres lebih lanjut tanpa hasil. Saya membuat tar.gzfile dari itu dir. Berikut polanya:

• rsync -av dir /nfs_mount/TEST/ = transfer paling lambat;
• rsync -av dir nfs_server-eth1:/nfs_mount/TEST/= rsync tercepat dengan bingkai jumbo diaktifkan; tanpa bingkai jumbo sedikit lebih lambat, tetapi masih secara signifikan lebih cepat daripada yang langsung ke NFS;
• rsync -av dir.tar.gz nfs_server-eth1:/nfs_mount/TEST/ = hampir sama dengan non-tar.gz yang setara;

Tes dengan cpdan scp:

• cp -r dir /nfs_mount/TEST/= sedikit lebih cepat daripada rsync -av dir /nfs_mount/TEST/tetapi masih jauh lebih lambat dari rsync -av dir nfs_server-eth1:/nfs_mount/TEST/.
• scp -r dir /nfs_mount/TEST/= keseluruhan tercepat, sedikit mengatasi rsync -av dir nfs_server-eth1:/nfs_mount/TEST/;
• scp -r dir.tar.gz /nfs_mount/TEST/ = hampir sama dengan non-tar.gz yang setara;

Kesimpulan, berdasarkan hasil ini: Untuk tes ini tidak ada perbedaan yang signifikan jika menggunakan file tar.gz besar atau banyak yang kecil. Frame jumbo hidup atau mati juga hampir tidak membuat perbedaan. cpdan scplebih cepat dari rsync -avpadanannya masing-masing . Menulis langsung ke pangsa NFS yang diekspor secara signifikan lebih lambat (setidaknya 2 kali) daripada menulis ke direktori yang sama melalui SSH, terlepas dari metode yang digunakan.

Perbedaan antara cpdan rsynctidak relevan dalam hal ini. Saya memutuskan untuk mencoba cpdan scphanya untuk melihat apakah mereka menunjukkan pola yang sama dan mereka melakukannya - perbedaan 2X.

Seperti yang saya gunakan rsyncatau cpdalam kedua kasus, saya tidak bisa mengerti apa yang mencegah NFS untuk mencapai kecepatan transfer dari perintah yang sama melalui SSH.

Kenapa menulis ke saham NFS 2X lebih lambat daripada menulis ke tempat yang sama melalui SSH?

Edit3 (NFS server / etc / ekspor pilihan): rw,no_root_squash,no_subtree_check,sync. Klien / proc / mounts menunjukkan: 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.

Terima kasih semua!

Mungkin ini bukan kecepatan transfer yang lebih lambat, tetapi meningkatkan latensi penulisan. Coba pasang async share NFS alih-alih sinkron dan lihat apakah itu menutup celah kecepatan. Ketika Anda rsync atas ssh, proses rsync jarak jauh menulis secara tidak sinkron (cepat). Tetapi ketika menulis ke berbagi nfs yang dipasang secara sinkron, penulisan tidak dikonfirmasi segera: server NFS menunggu sampai mereka mencapai disk (atau lebih mungkin cache controller) sebelum mengirim konfirmasi ke klien NFS bahwa penulisan berhasil.

Jika 'async' memperbaiki masalah Anda, ketahuilah bahwa jika sesuatu terjadi pada server NFS pada pertengahan penulisan Anda dengan sangat baik mungkin berakhir dengan data yang tidak konsisten pada disk. Selama pemasangan NFS ini bukan penyimpanan utama untuk data ini (atau lainnya), Anda mungkin akan baik-baik saja. Tentu saja Anda akan berada di kapal yang sama jika Anda menarik steker pada server nfs selama / setelah rsync-over-ssh berlari (mis. Rsync mengembalikan setelah 'selesai', server nfs crash, data yang tidak dikomit dalam cache tulis sekarang hilang meninggalkan data yang tidak konsisten pada disk).

Meskipun bukan masalah dengan pengujian Anda (rsyncing data baru), perlu diketahui bahwa rsync over ssh dapat membuat permintaan CPU dan IO yang signifikan pada server jarak jauh sebelum satu byte ditransfer saat menghitung checksum dan menghasilkan daftar file yang perlu diperbarui.

NFS adalah protokol berbagi, sementara Rsync dioptimalkan untuk transfer file; ada banyak optimasi yang dapat dilakukan ketika Anda tahu apriori bahwa tujuan Anda adalah menyalin file sekitar secepat mungkin alih-alih memberikan akses bersama kepada mereka.

Ini seharusnya membantu: http://en.wikipedia.org/wiki/Rsync

Rsync adalah protokol file yang hanya mentransfer bit yang diubah di antara file. NFS adalah protokol file direktori jarak jauh yang menangani semuanya setiap saat ... seperti SMB. Keduanya berbeda dan untuk tujuan yang berbeda. Anda bisa menggunakan Rsync untuk mentransfer antara dua saham NFS.

Ini menarik. Kemungkinan yang mungkin tidak Anda pertimbangkan adalah konten / jenis file yang Anda kirimkan.

Jika Anda memiliki berkas kecil (mis. Email dalam file individual), efisiensi NFS mungkin menurun karena tidak menggunakan MTU lengkap (mungkin ini lebih kecil kemungkinannya dengan TCP over UDP).

Atau, jika Anda memiliki file / data yang sangat kompresibel, CPU cepat, dan jaringan yang tidak memiliki kecepatan CPU (*), Anda bisa mendapatkan percepatan hanya dari kompresi implisit melalui tautan ssh.

Kemungkinan ketiga adalah bahwa file (atau satu versi daripadanya) sudah ada di tujuan. Dalam hal ini percepatan akan karena protokol rsync menghemat Anda mentransfer file.

(*) Dalam hal ini dengan 'kecepatan', saya mengacu pada tingkat di mana CPU dapat mengompres data dibandingkan dengan tingkat yang dapat ditransmisikan oleh jaringan, misalnya dibutuhkan 5 detik untuk mengirim 5MB melalui kabel, tetapi CPU dapat memampatkan 5MB itu menjadi 1MB dalam 1 detik. Dalam hal ini waktu transmisi data terkompresi Anda akan sedikit lebih dari 1 detik, sedangkan data yang tidak terkompresi adalah 5 detik.

Saya juga menggunakan -e "ssh Ciphers = arcfour" untuk meningkatkan throughput.

jika tujuan Anda adalah hanya menyalin semua file dari satu tempat ke tempat lain, maka tar / netcat akan menjadi opsi tercepat. jika Anda tahu bahwa Anda memiliki banyak spasi di file Anda (nol) maka gunakan opsi -i.

SUMBER: tar cvif - / path / to / source | nc DESTINASI PORTNUM TUJUAN: cd / path / ke / source && nc -l PORTNUM | tar xvif -

jika Anda tahu data Anda dapat dikompres, maka gunakan kompresi pada perintah tar Anda -z -j -Ipixz

Saya seorang penggemar pixz .. parallel xz, ia menawarkan kompresi hebat dan saya dapat menyetel jumlah cpu yang saya miliki untuk bandwidth jaringan. jika saya memiliki bandwidth yang lebih lambat saya akan menggunakan kompresi yang lebih tinggi jadi saya menunggu cpu lebih dari jaringan .. jika saya memiliki jaringan yang cepat saya akan menggunakan kompresi yang sangat rendah:

SUMBER: tar cvif - / path / to / source | pixz -2 -p12 | nc DESTINATION PORTNUM # tar, abaikan nol, kompresi level 2 pixz menggunakan 12 cpu core DESTINATION: nc -l PORTNUM | tar -Ipixz -xvif

jika Anda menyetel tingkat kompresi dan inti dengan benar, tergantung pada kumpulan data Anda, Anda harus dapat menjaga jaringan tetap dekat dengan saturasi dan melakukan kompresi yang cukup sehingga bottleneck Anda menjadi disk (biasanya sisi penulisan jika sistem disk baca dan tulis adalah sama).

Adapun rsync, saya percaya itu melompati nol sama dengan cara tar lakukan dengan opsi itu, jadi itu mentransmisikan data lebih sedikit daripada NFS. NFS tidak dapat membuat asumsi tentang data sehingga harus mengirimkan setiap byte bersama dengan overhead protokol NFS. rsync memiliki beberapa overhead ..

netcat pada dasarnya tidak ada .. ia akan mengirim paket TCP lengkap yang tidak berisi data apa pun yang Anda pedulikan.

dengan netcat, seperti halnya scp, Anda harus mengirim semua data sumber setiap saat, Anda tidak dapat selektif seperti dengan rsync sehingga tidak cocok untuk cadangan tambahan atau hal-hal semacam itu, tetapi bagus untuk menyalin data atau pengarsipan.

Apakah Anda memiliki pengaturan penguncian file di nfsshare? Anda mungkin mendapatkan lebih banyak dalm jika itu dinonaktifkan.

Saya berasumsi peningkatan kecepatan setidaknya sebagian karena "host rsync src: / path" menelurkan proses lokal pada mesin jarak jauh untuk mengirim / menerima, secara efektif memotong I / O Anda menjadi dua.