Mengapa scp sangat lambat dan bagaimana membuatnya lebih cepat?

59

Saya mencoba menyalin sejumlah file dengan scptetapi sangat lambat. Ini adalah contoh dengan 10 file:

$ time scp cap_* user@host:~/dir
cap_20151023T113018_704979707.png    100%  413KB 413.2KB/s   00:00    
cap_20151023T113019_999990226.png    100%  413KB 412.6KB/s   00:00    
cap_20151023T113020_649251955.png    100%  417KB 416.8KB/s   00:00    
cap_20151023T113021_284028464.png    100%  417KB 416.8KB/s   00:00    
cap_20151023T113021_927950468.png    100%  413KB 413.0KB/s   00:00    
cap_20151023T113022_567641507.png    100%  413KB 413.1KB/s   00:00    
cap_20151023T113023_203534753.png    100%  414KB 413.5KB/s   00:00    
cap_20151023T113023_855350640.png    100%  412KB 411.7KB/s   00:00    
cap_20151023T113024_496387641.png    100%  412KB 412.3KB/s   00:00    
cap_20151023T113025_138012848.png    100%  414KB 413.8KB/s   00:00    
cap_20151023T113025_778042791.png    100%  413KB 413.4KB/s   00:00    

real    0m43.932s
user    0m0.074s
sys 0m0.030s

Yang aneh adalah bahwa kecepatan transfer sekitar 413KB / s dan ukuran file sekitar 413KB sehingga benar-benar harus mentransfer satu file per detik, namun butuh sekitar 4,3 detik per file.

Adakah yang tahu dari mana overhead ini berasal, dan adakah cara untuk membuatnya lebih cepat?

scp time batch-jobs

— laurent
sumber

3

Kecepatan apa yang Anda harapkan (yaitu, apakah ada protokol lain yang menunjukkan kecepatan transfer yang lebih tinggi antara dua mesin yang sama)? Apa yang terjadi ketika Anda membuat file yang jauh lebih besar (mungkin gabungan dari semua file 413KB Anda)?

— Dhag

6

Sepertinya sistem jarak jauh mungkin mencoba menyelesaikan alamat IP klien untuk sebuah nama, dan Anda harus menunggu waktu tunggu sebelum sesi dilanjutkan. Anda dapat menyelidiki cara memperbaikinya (mis. Tambahkan alamat IP Anda ke file / etc / hosts tujuan).

— Wurtel

4

Perlu disebutkan bahwa flag -C memungkinkan kompresi selama transfer. Meskipun masalah Anda tampaknya adalah transfer awal untuk memulai, kompresi pada dasarnya "gratis" dan hampir selalu membantu.

— Sam

@wurtel: Saya tidak melihat apa yang Anda lihat, yang saya lihat adalah waktu. Seharusnya hanya ada satu panggilan balik DNS yang diperlukan.

— James Reinstate Monica Polk

Apakah Anda mengandalkan SCP untuk keamanan atau hanya untuk menyalin jarak jauh?

— Freiheit

17

Komentar @ wurtel mungkin benar: ada banyak overhead membangun setiap koneksi. Jika Anda dapat memperbaiki bahwa Anda akan mendapatkan transfer yang lebih cepat (dan jika Anda tidak bisa, cukup gunakan rsyncsolusi @ roaima ). Saya melakukan percobaan mentransfer file berukuran serupa ( head -c 417K /dev/urandom > foo.1dan membuat beberapa salinan file itu) ke host yang membutuhkan waktu untuk terhubung (HOST4) dan yang merespons dengan sangat cepat (HOST1):

$ time ssh $HOST1 echo


real    0m0.146s
user    0m0.016s
sys     0m0.008s
$ time scp * $HOST1:
foo.1                                         100%  417KB 417.0KB/s   00:00    
foo.2                                         100%  417KB 417.0KB/s   00:00    
foo.3                                         100%  417KB 417.0KB/s   00:00    
foo.4                                         100%  417KB 417.0KB/s   00:00    
foo.5                                         100%  417KB 417.0KB/s   00:00    

real    0m0.337s
user    0m0.032s
sys     0m0.016s
$ time ssh $HOST4 echo


real    0m1.369s
user    0m0.020s
sys     0m0.016s
$ time scp * $HOST4:
foo.1                                         100%  417KB 417.0KB/s   00:00    
foo.2                                         100%  417KB 417.0KB/s   00:00    
foo.3                                         100%  417KB 417.0KB/s   00:00    
foo.4                                         100%  417KB 417.0KB/s   00:00    
foo.5                                         100%  417KB 417.0KB/s   00:00    

real    0m6.489s
user    0m0.052s
sys     0m0.020s
$

1

Terima kasih, itu sangat menarik. Output scp agak rusak jika menunjukkan waktu yang sama walaupun itu benar-benar berbeda dari satu host ke yang lain. Mereka mungkin harus memasukkan waktu koneksi dalam total waktu.

— laurent

1

Jadi hipotesis Anda adalah membuat koneksi baru satu kali untuk setiap file?

— rogerdpack

59

Anda dapat menggunakan rsync(lebih ssh), yang menggunakan satu koneksi untuk mentransfer semua file sumber.

rsync -avP cap_* user@host:dir

Jika Anda tidak memiliki rsync(dan mengapa tidak !?) Anda dapat menggunakan tardengan sshseperti ini, yang menghindari membuat file sementara:

tar czf - cap_* | ssh user@host tar xvzfC - dir

Yang rsyncharus disukai, semua hal lain dianggap sama, karena dapat dimulai kembali jika terjadi gangguan.

— roaima
sumber

6

Apakah Anda mengatakan scppermohonan tunggal tidak akan menggunakan koneksi tunggal untuk mentransfer semua file?

— CVn

1

Dalam kasus tarpipe, tidak perlu untuk f -di setiap sisi, karena tar menghasilkan ke / membaca dari stdout / stdin secara default. Jadi tar cz cap_* | ssh user@host tar xvzC dirakan melakukannya.

— gemetar

1

@tremby belum tentu. tardapat dikompilasi dengan nilai default yang berbeda (lihat tar --show-defaultsapakah Anda menggunakan tar GNU, atau /etc/default/tarsebaliknya, dan dalam kedua kasus jangan lupa TAPEvariabel lingkungan)

— roaima

1

@ MichaelKjörling awalnya saya berasumsi bahwa scpakan membuat koneksi baru untuk setiap file, tetapi pada ingatan - dan setelah memeriksa ulang dengan tshark- saya menyadari bahwa saya salah. Pada titik ini saya tidak lagi yakin mengapa OP scpharus mengambil waktu yang lama per file.

— roaima

@roaima, menarik, terima kasih. Saya tidak pernah memperhatikan stdin / stdout tidak menjadi default sejauh ini. Tar BSD pada Mac saya di kantor tidak menyebutkan TAPE env var di halaman manualnya, meskipun tar GNU pada mesin Linux saya tidak.

— gemetar

15

Ini negosiasi negosiasi yang membutuhkan waktu. Secara umum, operasi pada n file b byte masing-masing membutuhkan lebih banyak waktu, lebih lama daripada operasi tunggal pada file tunggal n * b byte. Ini juga berlaku misalnya untuk disk I / O.

Jika Anda perhatikan dengan teliti, Anda akan melihat bahwa kecepatan transfer dalam kasus ini adalah size_of_the_file / detik.

Untuk mentransfer file lebih efisien, bundel bersama tar, lalu transfer tarball:

tar cvf myarchive.tar cap_20151023T*.png

atau, jika Anda juga ingin mengompresi arsip,

tar cvzf myarchive.tar.gz myfile*

Apakah kompres atau tidak tergantung pada konten file, mis. jika itu JPEG atau PNG, kompresi tidak akan berpengaruh apa pun.

— dr01
sumber

PNG menggunakan deflate, dan gzip juga tidak ada gunanya.

— Arthur2e5

Saya akan mengatakan bahwa karena mengompresi tar tidak memiliki efek negatif ketika file tidak dapat dikompresi lebih lanjut, ini adalah praktik yang baik untuk dilakukan-z

— Centimane

1

@Jika mereka tidak dapat dikompres, atau jaringannya cepat, itu akan memperlambat segalanya.

— Davidmh

@ Davidvid apakah ini dengan jumlah yang signifikan? Saya akan berpikir mengompresi file yang sudah dikompresi akan cukup cepat karena akan benar-benar hanya melihat apa yang bisa dikompres dan menemukan bahwa itu bukan apa-apa. Tergantung saya kira jika tarbiasanya melakukan pass kedua untuk kompresi atau jika itu akan mengompresi dan pengarsipan pada saat yang sama

— Centimane

3

@Dave dalam kasus saya (data pada 7000 rpm HD modern, CPU high-end, jaringan sangat cepat, tidak membual sama sekali), tar tanpa kompresi murni terikat IO, tetapi dengan -zterikat CPU, dan jauh lebih lambat. gzip akan selalu mencoba untuk mengompres, karenanya memperlambatnya; lagipula, Anda tidak dapat memastikan apakah serangkaian byte dapat dikompres hingga Anda mencoba mengompresnya. Dalam pengaturan saya, bahkan ketika mentransfer file teks biasa, rsync tanpa kompresi adalah yang tercepat dengan faktor 2-3 dibandingkan dengan kompresi paling ringan. Tentu saja, YMMV.

— Davidmh

6

Alasan lain bahwa scp lebih lambat dari yang seharusnya, terutama pada jaringan bandwidth tinggi, adalah bahwa ia memiliki buffer kontrol aliran internal yang ditentukan secara statis yang akhirnya menjadi hambatan kinerja jaringan.

HPN-SSH adalah versi patch OpenSSH yang meningkatkan ukuran buffer ini. Itu membuat perbedaan besar untuk kecepatan transfer scp (lihat grafik di situs, tetapi saya juga berbicara dari pengalaman pribadi). Tentu saja, untuk mendapatkan manfaat yang Anda butuhkan untuk menginstal HPN-SSH pada semua host Anda, tetapi itu sangat berharga jika Anda secara teratur perlu mentransfer file besar.

— Menno Smits
sumber

5

Saya telah menggunakan teknik yang dijelaskan di sini yang menggunakan gzip dan netcat paralel untuk dengan cepat memampatkan dan menyalin data.

Intinya adalah:

# SOURCE: 
> tar -cf - /u02/databases/mydb/data_file-1.dbf | pigz | nc -l 8888

# TARGET:
> nc <source host> 8888 | pigz -d | tar xf - -C /

Ini menggunakan tar untuk mengumpulkan file atau file. Kemudian menggunakan pigz untuk mendapatkan banyak thread cpu untuk mengkompres dan mengirim file, transmisi jaringan menggunakan netcat. Di sisi penerima, netcat mendengarkan lalu uncompresses (secara paralel) dan untar.

— Freiheit
sumber

3

nctidak dienkripsi. Tambahkan ssh -Dsihir mungkin?

— Arthur2e5

ini sebenarnya cukup brilian

— Jabran Saeed

5

Baru saja masalah ini melakukan transfer situs ke situs dari file mp4 besar melalui scp. Sudah mendapatkan ~ 250KB / s. Setelah menonaktifkan perlindungan banjir UDP (FP) pada firewall tujuan, kecepatan transfer meningkat menjadi 6,5MB / s. Ketika menyalakan kembali FP, nilai turun kembali ke ~ 250KB / s.

Pengirim: cygwin, Penerima: Fedora 20, Firewall Sophos UTM.

Untuk apa SSH menggunakan UDP? @ superuser.com - Tidak langsung dari apa yang saya baca.

Dalam meninjau log firewall, deteksi banjir terjadi pada port sumber & dest 4500 atas alamat IP publik, bukan alamat VPN internal internal situs-ke-situs. Jadi sepertinya masalah saya kemungkinan adalah situasi NAT Traversal di mana scpdata TCP pada akhirnya dienkripsi dan dienkapsulasi dalam paket ESP & UDP, dan akibatnya tunduk pada FP. Untuk menghapus scpdari persamaan, saya menjalankan operasi menyalin file Windows di VPN dan melihat kinerja serupa dengan scpdengan dan tanpa FP diaktifkan. Juga menjalankan iperftes melalui TCP dan melihat 2Mbits / detik dengan FP, dan 55Mbits / detik tanpa.

Bagaimana cara NAT-T bekerja dengan IPSec? @ cisco.com

— bvj
sumber