Mengapa scp dengan kompresi lebih lambat daripada tanpa?

11

Saya perlu mentransfer file vdisk KVM 20 GB , menyimpan root filesystem dari CentOS 6.5 VM, dari satu server lab ke yang lain. Ukuran file yang besar dan fakta bahwa saya pernah memampatkan file vdisk menjadi beberapa ratus mega-byte membuat saya secara naluriah mengaktifkan kompresi dengan scptetapi saya terkejut melihat kecepatan transfer yang agak rendah. Kemudian saya mencoba bzip2dalam kombinasi dengan sshdan catterkejut. Berikut ini adalah ringkasan metode dan throughput rata-rata.

scp -C vm1-root.img root@192.168.161.62:/mnt/vdisks/, 11 MB / s.
bzip2 -c vm1-root.img | ssh -l root 192.168.161.62 "bzip2 -d -c > /mnt/vdisks/vm1-root.img", 5 MB / s. Hasil yang lebih rendah ini mendorong pencarian di Internet.
scp -c arcfour -C vm1-root.img root@192.168.161.62:/mnt/vdisks/, 13 MB / s. Penggunaan -c arcfourseperti ini disarankan dalam satu jawaban di serverfault. Itu hampir tidak membantu. Akhirnya, saya menonaktifkan kompresi.
scp vm1-root.img root@192.168.161.62:/mnt/vdisks/, 23 MB / s.

Bukankah seharusnya kompresi lebih cepat?

EDIT: Saya tidak tahu mengapa pertanyaannya dibatalkan. Saya pikir ada sesuatu yang bisa dipelajari di sini.

Setelah menerima ssh(1)tip halaman manual dari @sven, saya mencoba beberapa metode alternatif transfer file yang tidak melibatkan kompresi, keduanya dengan hasil yang lebih baik.

cat vm1-root.img | ssh -l root 192.168.161.62 "cat > /mnt/vdisks/vm1-root.img", 26 MB / s.
nc -l 5678 > /mnt/vdisks/vm1-root.imgpada penerima dan nc 192.168.161.62 5678 < vm1-root.imgpada pemancar, 40 MB / s. Port tersebut 5678adalah porta arbitrer yang tersedia.

Menggunakan ncternyata menjadi metode penyalinan tercepat!

Di masa lalu, scp -Ctelah bekerja dengan sangat baik kapan pun saya berpikir akan melakukannya. Misalnya, saat mentransfer syslogs ( /var/log/messages*) berukuran beberapa GB. Laju transfer tanpa kompresi beberapa ratus KB / s akan meningkat menjadi 1-2 MB / s. Contoh ini jatuh dalam kasus koneksi yang lambat seperti yang telah ditunjukkan di halaman manual.

Saya punya kasus di mana, gambar vdisk yang baru dibuat untuk partisi 20 GB memiliki ukuran terkompresi hanya 200 MB. Dengan kecepatan transfer sekitar 25 MB / s, kita bisa menyalin hanya dalam 8 detik, bukan lebih dari 13 menit! Jelas, scptanpa kompresi tidak efisien dalam kasus ini dan scp -Cbahkan lebih buruk.

Saya kira, pelajaran utama yang dipelajari di sini adalah bahwa, scp -Charus dianggap hanya sebagai kenyamanan. Jika suatu file dapat dikompres secara signifikan, maka lebih baik kompres terlebih dahulu pada sumbernya, transfer formulir terkompresi dan akhirnya tekan kompres pada tujuan. Alat yang melakukan kompresi dan dekompresi dengan cepat (mis. Pbzip2 ) akan sangat membantu.

ssh scp file-transfer

— pdp
sumber

9

Mengutip man ssh(yang merupakan dasar yang digunakan oleh scp):

Kompresi diinginkan pada jalur modem dan koneksi lambat lainnya, tetapi hanya akan memperlambat hal-hal pada jaringan cepat.

Masalahnya adalah mengompresi data membutuhkan waktu lebih lama daripada hanya mengirimnya melalui jaringan.

— Sven
sumber

Dia secara khusus bertanya mengapa laju transfer lebih rendah, tetapi saya curiga ssh sebenarnya menghitung ini dengan membagi ukuran data dengan total waktu seluruh operasi, dan tidak memisahkan bagian di mana kompres data dan bagian di mana ia menyalin data di atas jaringan.

— Ernie

@ Ernie: Jika Anda dapat mengirimkan data dengan kecepatan 20 MB / s, dan sistem hanya dapat mengirimkannya dengan 15 MB / s karena kompresinya sangat lambat, itu akan ditransmisikan hanya dengan 15 MB / s. Hanya itu yang ada untuk itu.

— Sven

@ Ernie: Laju transfer yang dicetak oleh scptermasuk waktu yang dihabiskan untuk mengompresi / mendekompresi. Nilai yang dilaporkan akan tampak mengejutkan jika bukan ini masalahnya.

— pdp

0

Selain itu, di atas kompresi, nc mendapatkan tingkat terbaik karena juga tidak mengenkripsi. Dan kompresi non-lossy bergantung pada menemukan bagian data yang berlebihan, yang bila dilakukan pada tingkat jaringan Anda dapat melihat maksimum [ukuran buffer] byte di mana ketika dilakukan dengan seluruh file terlebih dahulu, itu [ukuran file] byte di mana untuk berburu dan mengolah kalimat byte duplikat.

Juga untuk memindahkan gambar disk, Anda harus menggunakan alat filesystem-sadar seperti ntfsclone / partclone karena bahkan kompresi tidak dapat mengalahkan hanya melewatkan blok yang tidak terisi - tingkat transfer Anda tidak terbatas jika Anda tidak perlu mentransfer data apa pun. Juga jangan lupa untuk menghancurkan swap dan file hibernasi pada partisi windows atau Anda menyalin sampah itu hanya akan membuang dan membuat ulang pula.

— Tony Butler
sumber