Dlaczego scp jest tak wolny i jak go przyspieszyć?

59

Próbuję skopiować partię plików, scpale jest to bardzo powolne. To jest przykład z 10 plikami:

$ 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

Dziwne jest to, że szybkość transferu wynosi około 413 KB / s, a rozmiar pliku to około 413 KB, więc naprawdę powinien przesyłać jeden plik na sekundę, jednak zajmuje to około 4,3 sekundy na plik.

Masz pojęcie, skąd bierze się ten narzut i czy jest jakiś sposób, aby przyspieszyć?

scp time batch-jobs

— Laurent
źródło

3

Jakiej prędkości oczekujesz (tj. Czy istnieje inny protokół, który pokazuje wyższe prędkości przesyłania między tymi samymi dwoma komputerami)? Co się stanie, gdy scpujesz znacznie większy plik (być może połączenie wszystkich plików 413 KB)?

— dhag

6

Wygląda na to, że zdalny system może próbować rozwiązać adres IP klienta na nazwę i musisz poczekać na przekroczenie limitu czasu przed kontynuacją sesji. Możesz sprawdzić, czy to naprawić (np. Dodaj swój adres IP do pliku docelowego / etc / hosts).

— wurtel

4

Warto wspomnieć, że flaga -C umożliwia kompresję podczas transferu. Chociaż wydaje się, że Twoim problemem są narzuty rozpoczynające przesyłanie, kompresja jest w zasadzie „darmowa” i prawie zawsze pomaga.

— Sam

@wurtel: Nie widzę tego, co widzisz, wszystko co widzę to czasy. W każdym razie powinno być potrzebne tylko jedno odwrotne połączenie DNS.

— James Reinstate Monica Polk

Czy polegasz na SCP dla bezpieczeństwa czy tylko na zdalnym kopiowaniu?

— Freiheit,

17

Komentarz @ wurtel jest prawdopodobnie poprawny: każde połączenie wiąże się z dużym nakładem pracy. Jeśli możesz to naprawić, otrzymasz szybsze transfery (a jeśli nie możesz, skorzystaj z rsyncobejścia @ roaima ). Zrobiłem eksperyment, przenosząc pliki o podobnej wielkości ( head -c 417K /dev/urandom > foo.1i wykonałem kilka kopii tego pliku) na host, który wymaga dłuższego czasu połączenia (HOST4) i taki, który reaguje bardzo szybko (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

Dzięki, to bardzo interesujące. Wyjście scp jest w pewnym sensie zepsute, jeśli pokazuje ten sam czas, mimo że jest całkowicie różne w różnych hostach. Powinny prawdopodobnie zawierać czas połączenia w łącznym czasie.

— laurent

1

Więc twoja hipoteza polega na tym, że tworzy nowe połączenie raz dla każdego pliku?

— rogerdpack

59

Możesz użyć rsync(over ssh), który używa pojedynczego połączenia do przesłania wszystkich plików źródłowych.

rsync -avP cap_* user@host:dir

Jeśli nie masz rsync(i dlaczego nie !?) można skorzystać tarz sshtakiego, który zapobiega tworzeniu tymczasowego pliku:

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

rsyncMa być preferowane, wszystkie inne rzeczy są równe, bo to restartowalne w przypadku wystąpienia zakłóceń.

— roaima
źródło

6

Czy mówisz, że pojedyncze scpwywołanie nie użyłoby jednego połączenia do przesłania wszystkich plików?

— CVn

1

W przypadku tarpipe nie ma potrzeby z f -każdej strony, ponieważ tar domyślnie wypisuje / odczytuje ze stdout / stdin. Więc tar cz cap_* | ssh user@host tar xvzC dirbyłoby to zrobić.

— tremby

1

@tremby niekoniecznie. tarmoże być skompilowany z różnymi wartościami domyślnymi (sprawdź, tar --show-defaultsczy używasz GNU tar, lub w /etc/default/tarinny sposób, aw obu przypadkach nie zapomnij o TAPEzmiennej środowiskowej)

— roaima 24.10.2015

1

@ MichaelKjörling początkowo zakładałem, scpże stworzy nowe połączenie dla każdego pliku, ale po przypomnieniu - i po podwójnym sprawdzeniu z tshark- zdałem sobie sprawę, że się mylę. W tym momencie nie jestem już pewien, dlaczego OP scppowinno tak długo zajmować plik.

— roaima

@roaima, ciekawe, dzięki. Do tej pory nigdy nie zauważyłem, że standardowe wejście / standardowe wyjście nie jest domyślne. Tar BSD na moim Macu w pracy nie wspomina o zmiennej env TAPE na swojej stronie podręcznika, chociaż tar GNU na moim komputerze z Linuxem.

— tremby

15

To negocjacja przeniesienia wymaga czasu. W ogóle, operacje na n akt b bajtów każdy trwa o wiele dłużej niż jednej operacji na pojedynczym pliku z n * b bajtów. Dotyczy to również np. Dyskowych operacji we / wy.

Jeśli przyjrzysz się uważnie, zobaczysz, że szybkość transferu w tym przypadku wynosi rozmiar_pliku / s.

Aby przesłać pliki bardziej efektywnie, połącz je razem z tar, a następnie przenieś plik archiwalny:

tar cvf myarchive.tar cap_20151023T*.png

lub, jeśli chcesz również skompresować archiwum,

tar cvzf myarchive.tar.gz myfile*

To, czy kompresować, czy nie, zależy od zawartości pliku, np. jeśli są to pliki JPEG lub PNG, kompresja nie przyniesie żadnego efektu.

— dr01
źródło

Pliki PNG używają deflacji, a gzipowanie ich również nie ma sensu.

— Arthur2e5

Powiedziałbym, że ponieważ kompresja tar nie ma negatywnych skutków, gdy pliki nie mogą być dalej kompresowane, dobrą praktyką jest po prostu umieścić-z

— Centimane

1

@Dave, jeśli nie można ich skompresować lub sieć jest szybka, spowoduje to spowolnienie.

— Davidmh

@Davidmh byłoby to jednak znaczną kwotą? Myślałem, że skompresowanie już skompresowanego pliku byłoby dość szybkie, ponieważ tak naprawdę po prostu sprawdziłby, co może skompresować i stwierdziłby, że to nic. Zależy, jak sądzę, czy tarnormalnie wykonuje drugie przejście do kompresji, czy też byłoby to kompresowanie i archiwizacja w tym samym czasie

— Centimane

3

@Dave w moim przypadku (dane na nowoczesnym HD 7000 rpm, wysokiej klasy procesor, bardzo szybka sieć, w ogóle się nie chwaląc), tar bez kompresji jest ściśle związany z IO, ale z -zjest związany z procesorem i znacznie wolniejszy. gzip zawsze będzie próbował kompresować, stąd spowolnienie; w końcu nie można stwierdzić, czy ciąg bajtów jest kompresowalny, dopóki nie spróbujesz go skompresować. W moim ustawieniu, nawet przy przesyłaniu zwykłych plików tekstowych, rsync bez kompresji jest najszybszy 2-3 razy w porównaniu z najlżejszą kompresją. Oczywiście, YMMV.

— Davidmh

6

Innym powodem, dla którego scp jest wolniejszy niż powinien, szczególnie w sieciach o dużej przepustowości, jest to, że ma statycznie zdefiniowane bufory wewnętrznej kontroli przepływu, które stają się wąskimi gardłami wydajności sieci.

HPN-SSH to łatana wersja OpenSSH, która zwiększa rozmiar tych buforów. Ma to ogromną różnicę w szybkości transferu scp (patrz tabele na stronie, ale mówię również z własnego doświadczenia). Oczywiście, aby uzyskać korzyści, musisz zainstalować HPN-SSH na wszystkich swoich hostach, ale warto, jeśli musisz regularnie przesyłać duże pliki.

— Menno Smits
źródło

5

Użyłem opisanej tutaj techniki , która wykorzystuje równoległe gzip i netcat do szybkiego kompresowania i kopiowania danych.

Sprowadza się do:

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

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

Używa tar do zebrania pliku lub plików. Następnie używa pigz, aby uzyskać wiele wątków procesora do skompresowania i wysłania pliku, transmisja sieciowa używa netcat. Po stronie odbierającej netcat nasłuchuje, a następnie rozpakowuje (równolegle) i rozpakowuje.

— Freiheit
źródło

3

ncnie jest szyfrowany. ssh -DMoże dodać trochę magii?

— Arthur2e5

to jest naprawdę genialne

— Jabran Saeed

5

Właśnie miałem ten problem podczas przesyłania dużego pliku mp4 z witryny na witrynę scp. Dostawał ~ 250 KB / s. Po wyłączeniu ochrony przeciwpowodziowej UDP na docelowej zaporze ogniowej szybkość przesyłania wzrosła do 6,5 MB / s. Po ponownym włączeniu FP szybkość spadła z powrotem do ~ 250 KB / s.

Nadawca: cygwin, Odbiorca: Fedora 20, Firewall Sophos UTM.

Do czego SSH używa UDP? @ superuser.com - Nie pochodzi bezpośrednio z tego, co przeczytałem.

Podczas przeglądania dziennika zapory sieciowej wykryto powódź na portach źródłowym i docelowym 4500 na publicznych adresach IP, a nie na wewnętrznych adresach VPN między lokacjami. Wygląda więc na to, że moim problemem jest prawdopodobnie sytuacja NAT NAT, w której scpdane TCP są ostatecznie szyfrowane i enkapsulowane w pakietach ESP i UDP, a zatem podlegają FP. Aby usunąć scpz równania, uruchomiłem operację kopiowania plików systemu Windows w sieci VPN i zauważyłem podobną wydajność scpz włączoną i wyłączoną funkcją FP. Przeprowadziłem również iperftest przez TCP i zauważyłem 2 Mb / s przy FP i 55 Mb / s bez.

Jak działa NAT-T z IPSec? @ cisco.com

— bvj
źródło