Saya sering menemukan diri saya mengirim folder dengan 10K - 100K file ke mesin jarak jauh (dalam jaringan yang sama di kampus).

Saya hanya ingin tahu apakah ada alasan untuk percaya itu,

 tar + rsync + untar

Atau sederhananya

 tar (from src to dest) + untar

bisa lebih cepat dalam praktek daripada

rsync 

saat mentransfer file untuk pertama kalinya .

Saya tertarik pada jawaban yang membahas hal di atas dalam dua skenario: menggunakan kompresi dan tidak menggunakannya.

Memperbarui

Saya baru saja menjalankan beberapa percobaan memindahkan 10.000 file kecil (ukuran total = 50 MB), dan tar+rsync+untarsecara konsisten lebih cepat daripada berjalan rsyncsecara langsung (keduanya tanpa kompresi).

Ketika Anda mengirim set file yang sama, rsynclebih cocok karena hanya akan mengirim perbedaan. tarakan selalu mengirim semuanya dan ini adalah pemborosan sumber daya ketika banyak data sudah ada. The tar + rsync + untarkehilangan keuntungan ini dalam kasus ini, serta keuntungan dari menjaga folder di-sync dengan rsync --delete.

Jika Anda menyalin file untuk pertama kalinya, mengemas terlebih dahulu, kemudian mengirim, kemudian membongkar (AFAIK rsynctidak mengambil input pipa) adalah rumit dan selalu lebih buruk daripada hanya rsyncing, karena rsynctidak harus melakukan tugas lebih dari apa pun tar.

Tip: rsync versi 3 atau yang lebih baru melakukan rekursi tambahan, artinya mulai menyalin segera sebelum menghitung semua file.

Tip2: Jika Anda menggunakan rsynclebih dari ssh, Anda juga dapat menggunakan keduanyatar+ssh

tar -C /src/dir -jcf - ./ | ssh user@server 'tar -C /dest/dir -jxf -'

atau hanya scp

scp -Cr srcdir user@server:destdir

Aturan umum, sederhanakan.

MEMPERBARUI:

Saya telah membuat data demo 59M

mkdir tmp; cd tmp
for i in {1..5000}; do dd if=/dev/urandom of=file$i count=1 bs=10k; done

dan menguji beberapa kali transfer file ke server jauh (tidak dalam lan yang sama), menggunakan kedua metode

time rsync -r  tmp server:tmp2

real    0m11.520s
user    0m0.940s
sys     0m0.472s

time (tar cf demo.tar tmp; rsync demo.tar server: ; ssh server 'tar xf demo.tar; rm demo.tar'; rm demo.tar)

real    0m15.026s
user    0m0.944s
sys     0m0.700s

sambil menyimpan log terpisah dari paket lalu lintas ssh yang dikirim

wc -l rsync.log rsync+tar.log 
   36730 rsync.log
   37962 rsync+tar.log
   74692 total

Dalam hal ini, saya tidak dapat melihat keuntungan dalam lebih sedikit lalu lintas jaringan dengan menggunakan rsync + tar, yang diharapkan ketika mtu default adalah 1500 dan sementara file berukuran 10k. rsync + tar menghasilkan lebih banyak traffic, lebih lambat selama 2-3 detik dan meninggalkan dua file sampah yang harus dibersihkan.

Saya melakukan tes yang sama pada dua mesin pada lan yang sama, dan di sana rsync + tar melakukan jauh lebih baik dan lebih sedikit lalu lintas jaringan. Saya berasumsi penyebab frame jumbo.

Mungkin rsync + tar akan lebih baik daripada hanya rsync pada kumpulan data yang jauh lebih besar. Tapi terus terang saya tidak berpikir itu sepadan dengan masalah, Anda perlu ruang ganda di setiap sisi untuk berkemas dan membongkar, dan ada beberapa opsi lain seperti yang telah saya sebutkan di atas.

rsyncjuga melakukan kompresi. Gunakan -zbendera. Jika berlari ssh, Anda juga dapat menggunakan mode kompresi ssh. Perasaan saya adalah bahwa tingkat kompresi berulang tidak berguna; itu hanya akan membakar siklus tanpa hasil yang signifikan. Saya akan merekomendasikan bereksperimen dengan rsynckompresi. Tampaknya cukup efektif. Dan saya sarankan berhenti menggunakan taratau kompresi pra / post lainnya.

Saya biasanya menggunakan rsync sebagai rsync -abvz --partial....

Saya harus membuat cadangan direktori rumah saya ke NAS hari ini dan berlari ke diskusi ini, berpikir saya akan menambahkan hasil saya. Singkatnya, tar'ing melalui jaringan ke sistem file target jauh lebih cepat di lingkungan saya daripada rsyncing ke tujuan yang sama.

Lingkungan: Mesin sumber desktop i7 menggunakan hard drive SSD. Mesin tujuan Synology NAS DS413j pada koneksi gigabit dan ke mesin Sumber.

Spesifikasi pasti dari kit yang terlibat akan berdampak pada kinerja, secara alami, dan saya tidak tahu detail pengaturan persis saya terkait dengan kualitas perangkat keras jaringan di setiap ujungnya.

File sumber adalah folder ~ / .cache saya yang berisi 1.2Gb file yang sangat kecil.

1a/ tar files from source machine over the network to a .tar file on remote machine

$ tar cf /mnt/backup/cache.tar ~/.cache

1b/ untar that tar file on the remote machine itself

$ ssh admin@nas_box
[admin@nas_box] $ tar xf cache.tar

2/ rsync files from source machine over the network to remote machine

$ mkdir /mnt/backup/cachetest
$ rsync -ah .cache /mnt/backup/cachetest

Saya menjaga 1a dan 1b sebagai langkah yang sepenuhnya terpisah hanya untuk menggambarkan tugas. Untuk aplikasi praktis, saya akan merekomendasikan apa yang diposting Gilles di atas yang melibatkan keluaran tar pipa melalui ssh ke proses tanpa tanda pada penerima.

Pengaturan waktu:

1a - 33 seconds

1b - 1 minutes 48 seconds

2 - 22 minutes

Sangat jelas bahwa rsync berkinerja sangat buruk dibandingkan dengan operasi tar, yang mungkin dapat dikaitkan dengan kinerja jaringan yang disebutkan di atas.

Saya akan merekomendasikan siapa saja yang ingin mencadangkan sebagian besar file kecil sebagian besar, seperti cadangan direktori home, gunakan pendekatan tar. rsync tampaknya pilihan yang sangat buruk. Saya akan kembali ke posting ini jika sepertinya saya tidak akurat dalam prosedur saya.

Nick

Menggunakan rsync untuk mengirim arsip tar seperti yang diminta sebenarnya merupakan pemborosan atau sumber daya, karena Anda akan menambahkan lapisan verifikasi ke proses. Rsync akan memeriksa file tar untuk kebenaran, ketika Anda lebih suka memiliki cek pada file individual. (Tidak membantu mengetahui bahwa file tar yang mungkin rusak pada sisi pengirim sudah menunjukkan efek yang sama pada sisi penerima). Jika Anda mengirim arsip, ssh / scp adalah yang Anda butuhkan.

Salah satu alasan Anda mungkin harus memilih mengirim arsip adalah jika tar pilihan Anda dapat mempertahankan lebih banyak spesial sistem file, seperti Access Control List atau Metadata lain yang sering disimpan dalam Atribut yang Diperluas (Solaris) atau Ressource Forks (MacOS ). Ketika berhadapan dengan hal-hal seperti itu, perhatian utama Anda adalah mengenai alat mana yang dapat menyimpan semua informasi yang terkait dengan file pada sistem file sumber, menyediakan sistem file target memiliki kemampuan untuk melacaknya juga.

Ketika kecepatan menjadi perhatian utama Anda, itu tergantung banyak pada ukuran file Anda. Secara umum, banyak file kecil akan berskala buruk di atas rsync atau scp, karena semuanya akan membuang masing-masing paket jaringan, di mana file tar akan menyertakan beberapa di antaranya dalam beban data paket jaringan tunggal. Bahkan lebih baik jika file tar dikompresi, karena file kecil kemungkinan besar akan dikompres lebih baik secara keseluruhan daripada individual. Sejauh yang saya tahu, baik rsync dan scp gagal untuk mengoptimalkan ketika mengirim seluruh file tunggal seperti dalam transfer awal, masing-masing file menempati seluruh kerangka data dengan seluruh overhead protokol (dan membuang lebih banyak untuk memeriksa balik dan kembali). Namun Janecekmenyatakan ini hanya berlaku untuk scp, menentukan bahwa rsync akan mengoptimalkan lalu lintas jaringan tetapi dengan biaya membangun struktur data besar dalam memori. Lihat artikel Transfer File yang Efisien, Janecek 2006 . Jadi menurutnya masih benar bahwa scp dan rsync berskala buruk pada file kecil, tetapi untuk alasan yang sama sekali berbeda. Kira saya harus menggali sumber akhir pekan ini untuk mencari tahu.

Untuk relevansi praktis, jika Anda tahu Anda mengirim sebagian besar file yang lebih besar, tidak akan ada banyak perbedaan dalam kecepatan, dan menggunakan rsync memiliki manfaat tambahan karena dapat mengambil di mana ia pergi ketika terganggu.

Postscriptum: Hari-hari ini, rdist tampaknya tenggelam ke dalam penghapusan, tetapi sebelum zaman rsync, itu adalah alat yang sangat mampu dan digunakan secara luas (aman bila digunakan lebih dari ssh, sebaliknya tidak aman). Saya tidak akan melakukan sebaik rsync karena tidak mengoptimalkan hanya mentransfer konten yang telah berubah. Perbedaan utama dengan rsync terletak pada cara konfigurasi, dan bagaimana aturan untuk memperbarui file dijelaskan.

Untuk direktori kecil (kecil seperti dalam ruang disk yang digunakan), itu tergantung pada overhead memeriksa informasi file untuk file yang sedang disinkronkan. Di satu sisi, rsyncmenghemat waktu transfer file yang tidak dimodifikasi, di sisi lain, memang harus mentransfer informasi tentang setiap file.

Saya tidak tahu persis bagian dalamnya rsync. Apakah statistik file menyebabkan kelambatan tergantung pada bagaimana rsynctransfer data - jika statistik file ditransfer satu per satu, maka RTT dapat membuat tar + rsync + untar lebih cepat.

Tetapi jika Anda memiliki, katakanlah 1 GiB data, rsync akan jauh lebih cepat, well, kecuali koneksi Anda sangat cepat!

Saya harus memindahkan beberapa terabyte data di seluruh negeri, tepat sekali. Sebagai percobaan, saya menjalankan dua transfer menggunakan rsyncdan ssh/taruntuk melihat bagaimana mereka membandingkan.

Hasil:

• rsync mentransfer file dengan kecepatan rata-rata 2,76 megabyte per detik.
• ssh/tar mentransfer file dengan kecepatan rata-rata 4,18 megabyte per detik.

Detailnya: Data saya terdiri dari jutaan file terkompresi .gz, ukuran rata-rata 10 megabyte tetapi beberapa lebih dari satu gigabyte. Ada struktur direktori tetapi dikerdilkan oleh ukuran data di dalam file. Jika saya memiliki hampir semua hal untuk dilakukan, saya hanya akan menggunakan rsynctetapi dalam kasus ini, ssh/tarini adalah solusi fungsional.

Pekerjaan saya dengan rsyncterdiri dari:

rsync --compress --stats --no-blocking-io --files-from=fileList.txt -av otherSystem:/the/other/dir/ dest/

di mana fileList.txt adalah daftar panjang yang bagus dari nama path relatif dari file di sisi lain. (Saya perhatikan bahwa --compressitu tidak produktif untuk file terkompresi setelah saya mulai tetapi saya tidak akan kembali restart.)

Saya memulai yang lain dengan ssh dan tar yang memiliki:

ssh otherSystem "cd /the/other/dir/;  tar cf - ." | tar xvf -

Anda akan melihat salinan ini semuanya, maaf ini bukan 100% perbandingan apel dengan apel.

Saya harus menambahkan bahwa ketika saya menggunakan jaringan internal perusahaan, saya harus melalui perantara untuk sampai ke komputer sumber data. Waktu ping dari komputer target saya ke perantara adalah 21 ms dan dari perantara ke sumber data adalah 26 ms. Ini sama untuk kedua transfer.

Koneksi SSL melalui perantara diselesaikan melalui ~/.ssh/configentri:

Host otherSystem
    Hostname dataSource.otherSide.com
    User myUser
    Port 22
    ProxyCommand ssh -q -W %h:%p intermediary.otherSide.com
    IdentityFile   id_rsa.priv

Waktu ini:

tar cf - ~/.cache | ssh admin@nas_box "(cd /destination ; tar xf -)"