Scp neden bu kadar yavaş ve nasıl daha hızlı hale getirilebilir?

Bir toplu iş dosyasını kopyalamaya çalışıyorum scpancak çok yavaş. Bu, 10 dosya içeren bir örnektir:

$ 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

Tuhaf olan şey, aktarım hızının yaklaşık 413KB / sn ve dosya boyutunun yaklaşık 413KB olması, yani saniyede bir dosya aktarması gerekiyor, ancak dosya başına yaklaşık 4,3 saniye sürüyor.

Bu ek yükün nereden geldiğine dair herhangi bir fikir ve daha hızlı hale getirmenin bir yolu var mı?

@ wurtel'in yorumu muhtemelen doğru: her bağlantıyı kuran bir sürü ek yük var. Eğer daha hızlı transferler alacağınızı düzeltebilirseniz (ve bu mümkün değilse, sadece @ roaima'nın rsyncgeçici çözümünü kullanın ). Benzer boyuttaki dosyaları ( head -c 417K /dev/urandom > foo.1ve bu dosyanın bazı kopyalarını) bağlantı kurması biraz zaman alan (HOST4) ve çok hızlı yanıt veren bir ana bilgisayara (HOST1) aktarırken bir deneme yaptım:

$ 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
$ 

Tüm kaynak dosyaları aktarmak için tek bir bağlantı kullanan rsync(üstü ssh) kullanabilirsiniz .

rsync -avP cap_* user@host:dir

Eğer sahip değilseniz rsync(ve neden olmasın !?), tarbununla birlikte kullanabilirsiniz ; sshbu, geçici bir dosya oluşturmaktan kaçınır:

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

rsyncBir kesinti durumunda restartable, çünkü tüm diğer şeyler eşit olduğunda, tercih edilmelidir.

Zaman alan transferin müzakeresi. Genel olarak, her bir b bayt n dosyalarındaki işlemler, tek bir n * b bayt dosyadaki tek bir işlemden çok daha uzun sürer . Bu aynı zamanda örneğin disk I / O için de geçerlidir.

Dikkatli bakarsanız, bu durumda transfer hızının size_of_the_file / sn. Olduğunu göreceksiniz .

Dosyaları daha verimli bir şekilde taraktarmak için, onları bir araya toplayın, sonra tarball'ı aktarın:

tar cvf myarchive.tar cap_20151023T*.png

veya arşivi sıkıştırmak istiyorsanız,

tar cvzf myarchive.tar.gz myfile*

Sıkıştırıp sıkıştırmama dosya içeriğine bağlıdır, örn. eğer JPEG ya da PNG ise, sıkıştırmanın bir etkisi olmaz.

Scp'nin, özellikle yüksek bant genişlikli ağlarda olması gerekenden daha yavaş olmasının bir başka nedeni, ağ performans darboğazı haline gelen statik olarak tanımlanmış iç akış kontrol tamponlarına sahip olmasıdır.

HPN-SSH , bu arabelleklerin boyutunu artıran yamalı bir OpenSSH sürümüdür. Scp transfer hızı için çok büyük bir fark yaratıyor (sitedeki çizelgelere bakın, ama aynı zamanda kişisel tecrübemden de bahsediyorum). Tabii ki, HPN-SSH'yi tüm ana bilgisayarlarınıza yüklemeniz gerekir, ancak düzenli olarak büyük dosyaları aktarmanız gerekirse, buna değer.

Burada açıklanan tekniği hızlı bir şekilde veri sıkıştırmak ve kopyalamak için paralel gzip ve netcat kullanan teknik kullandım.

Aşağı kaynar:

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

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

Bu dosya veya dosyaları toplamak için tar kullanır. Sonra dosya sıkıştırma ve göndermek için birçok cpu iş parçacığı almak için pigz kullanır, ağ iletimi netcat kullanıyor. Alıcı tarafta, netcat daha sonra sıkıştırır (paralel olarak) ve yıldızları kaldırır.

Az önce bu sorunu büyük bir mp4 dosyasının siteden siteye aktarmasıyla yaptım scp. ~ 250KB / s alıyordu. Hedef güvenlik duvarındaki UDP taşkın korumasını (FP) devre dışı bıraktıktan sonra, aktarım hızı 6,5 MB / sn'ye yükseldi. FP'yi tekrar açarken, oran ~ 250KB / s'ye düştü.

Gönderen: cygwin, Alıcı: Fedora 20, Güvenlik Duvarı Sophos UTM.

SSH UDP'yi ne için kullanıyor? @ superuser.com - Doğrudan okuduklarımdan değil.

Güvenlik duvarı günlüğünü incelerken, özel siteden siteye dahili VPN adresleri yerine, genel IP adresleri üzerinden hem kaynak hem de dest portlarında (4500) taşkın tespiti meydana geldi. Bu yüzden benim sorunum muhtemelen scpTCP verilerinin ESP ve UDP paketlerinde en sonunda şifrelendiği ve saklandığı ve sonuçta FP'ye tabi tutulduğu bir NAT Geçiş durumu gibi görünüyor . scpDenklemden çıkarmak için, VPN'de bir Windows dosya kopyalama işlemi yürüttüm ve scpFP etkin ve etkin olmayan benzer performanslar gördüm . Ayrıca iperfTCP üzerinden bir test yürüttü ve FP ile 2Mbits / sn ve olmadan 55Mbits / sn farkettim.

NAT-T IPSec ile Nasıl Çalışır? @ cisco.com