Próbuję skopiować partię plików, scp
ale 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
źródło
Odpowiedzi:
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
rsync
obejścia @ roaima ). Zrobiłem eksperyment, przenosząc pliki o podobnej wielkości (head -c 417K /dev/urandom > foo.1
i 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):źródło
Możesz użyć
rsync
(overssh
), który używa pojedynczego połączenia do przesłania wszystkich plików źródłowych.Jeśli nie masz
rsync
(i dlaczego nie !?) można skorzystaćtar
zssh
takiego, który zapobiega tworzeniu tymczasowego pliku:rsync
Ma być preferowane, wszystkie inne rzeczy są równe, bo to restartowalne w przypadku wystąpienia zakłóceń.źródło
scp
wywołanie nie użyłoby jednego połączenia do przesłania wszystkich plików?f -
każdej strony, ponieważ tar domyślnie wypisuje / odczytuje ze stdout / stdin. Więctar cz cap_* | ssh user@host tar xvzC dir
byłoby to zrobić.tar
może być skompilowany z różnymi wartościami domyślnymi (sprawdź,tar --show-defaults
czy używasz GNU tar, lub w/etc/default/tar
inny sposób, aw obu przypadkach nie zapomnij oTAPE
zmiennej środowiskowej)scp
że stworzy nowe połączenie dla każdego pliku, ale po przypomnieniu - i po podwójnym sprawdzeniu ztshark
- zdałem sobie sprawę, że się mylę. W tym momencie nie jestem już pewien, dlaczego OPscp
powinno tak długo zajmować plik.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.
źródło
-z
tar
normalnie wykonuje drugie przejście do kompresji, czy też byłoby to kompresowanie i archiwizacja w tym samym czasie-z
jest 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.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.
źródło
Użyłem opisanej tutaj techniki , która wykorzystuje równoległe gzip i netcat do szybkiego kompresowania i kopiowania danych.
Sprowadza się do:
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.
źródło
nc
nie jest szyfrowany.ssh -D
Może dodać trochę magii?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
scp
dane TCP są ostatecznie szyfrowane i enkapsulowane w pakietach ESP i UDP, a zatem podlegają FP. Aby usunąćscp
z równania, uruchomiłem operację kopiowania plików systemu Windows w sieci VPN i zauważyłem podobną wydajnośćscp
z włączoną i wyłączoną funkcją FP. Przeprowadziłem równieżiperf
test 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
źródło