Mengapa rsync lebih cepat dari NFS?


40

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!


Apakah ini hasil yang sama untuk banyak file kecil dan satu file besar?
Xiè Jìléi

@ notpeter - menambahkan opsi dalam posting asli. Terima kasih!
grs

Saya menyadari ini adalah pertanyaan yang agak lama, tetapi satu perbedaan besar antara SCP dan rsync yang tidak menyebabkan sedikit perbedaan dalam waktu transfer adalah checksum transfer file otomatis yang dilakukan untuk menunjukkan bahwa file tersebut ditransfer dengan benar. Ini berbeda dari opsi -c dari rsync yang menggunakan checksum untuk memvalidasi jika file telah diperbarui antara host. Jika Anda hanya mengatasi file baru yang tidak ikut bermain.
Rowan Hawkins

Jawaban:


20

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.


1
Saya pikir jawaban ini adalah yang benar. Jika media (disk) pada kedua mesin tersebut sebanding (konfigurasi RPM / bandwidth / RAID yang sama), Anda bisa mendapatkan ide yang bagus mengenai apakah ini masalahnya dengan melakukan operasi terbalik: 'rsync -av / nfs_mount / TEST / dir 'Kalau tidak, mematikan sinkronisasi dan mencoba itu adalah cara untuk menguji.
Slartibartfast

Saya melakukan tes cepat dengan sinkronisasi vs async dan saya pikir jawaban ini memiliki peluang besar untuk menjadi yang benar. Memilih async menutup celah secara signifikan, tetapi masih sedikit lebih lambat daripada SSH. Saya akan melakukan tes lebih lanjut dan memberi tahu kalian. Terima kasih banyak!
grs

3
Pembaruan: tes baru saya menunjukkan perbedaan yang signifikan dalam hal kecepatan sinkronisasi vs opsi ekspor NFS async. Dengan NFS dipasang dengan async dan rsync -av dir.tar.gz /nfs_mount/TEST/saya mendapatkan kecepatan transfer yang sama dengan rsync -av dir nfs_server-eth1:/nfs_mount/TEST/. Saya akan menandai jawaban ini sebagai jawaban yang benar, tetapi saya ingin tahu apakah saya dapat meningkatkan pengaturan lebih lanjut. Terima kasih! Notpeter dilakukan dengan baik!
grs

22

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


2
Jika Anda mengetahui data sebelumnya (yang biasanya Anda lakukan), Anda dapat mematikan kompresi secara selektif dengan opsi -e "ssh Compression=no"untuk mendapatkan kecepatan transfer yang lebih cepat. Ini akan mencegahnya mengompresi file yang mungkin sudah dikompresi. Saya perhatikan kecepatan banyak kali.
lsd

5
@lsd - ssh kompresi biasanya mati secara default, dan tidak disarankan untuk rsync. Membiarkan rsync untuk kompres data dengan pilihan -z, --compress-leveldan --skip-compressakan mendapatkan tha kinerja yang lebih baik dengan transportasi terkompresi.
JimB

5

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.


6
Saya merasa sedikit tidak enak memilih Anda karena Anda tidak mengatakan sesuatu yang salah secara teknis, tetapi sepertinya Anda tidak menambahkan apa pun pada diskusi, dan Anda masuk setelah informasi yang lebih spesifik disediakan. Juga, dari jabatannya sepertinya penulis menyadari hal-hal ini.
Slartibartfast

Saya pikir saya adalah posting kedua dan yang pertama menyebutkan bahwa keduanya adalah protokol dengan tujuan yang berbeda dalam pikiran. Tidak apa-apa, saya pikir suntingan pertama dari pertanyaan itu agak bodoh.
pcunite

3

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.


Sangat bagus! File yang saya uji dengan banyak gambar kecil. Mereka bervariasi dalam ukuran. Saya harus mengecek apakah saya dapat mengompres lebih lanjut. File-file pasti tidak ada di tempat tujuan, karena saya mulai dari awal setiap waktu. Besok, saya akan melakukan tes dengan cp -rvs sederhana rsyncdan kemudian saya akan memampatkan file untuk memiliki file yang lebih besar untuk mendapatkan manfaat dari MTU. Terima kasih!
grs

1

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


1
Membutuhkan "-o". yaitu: "rsync -va -e" ssh -o Ciphers = arcfour "sumber tujuan: / destination /"
Pete Ashdown

1

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.



-1

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.