Dlaczego scp z kompresją jest wolniejszy niż bez?

Musiałem przenieść plik vdisk KVM o pojemności 20 GB , przechowujący główny system plików maszyny Wirtualnej CentOS 6.5 z jednego serwera laboratoryjnego na drugi. Duży rozmiar pliku i fakt, że kiedyś skompresowałem taki plik vdisk do kilkuset megabajtów, sprawiły, że instynktownie umożliwiłem kompresję, scpale byłem zaskoczony, widząc raczej niską prędkość transferu. Potem próbowałem bzip2w połączeniu z ssha cati był zaskoczony. Oto podsumowanie metod i średniej przepustowości.

• 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. Ten jeszcze niższy wynik skłonił do wyszukiwania w sieci.
• scp -c arcfour -C vm1-root.img root@192.168.161.62:/mnt/vdisks/, 13 MB / s. Takie użycie -c arcfourjak sugerowano w jednej odpowiedzi dotyczącej błędu serwera. To prawie nie pomogło. W końcu wyłączyłem kompresję.
• scp vm1-root.img root@192.168.161.62:/mnt/vdisks/, 23 MB / s.

Czy kompresja nie powinna być szybsza?

EDYCJA: Nie wiem, dlaczego pytanie zostało odrzucone. Myślałem, że jest tu coś do nauczenia.

Po otrzymaniu ssh(1)końcówki strony podręcznika od @sven wypróbowałem kilka alternatywnych metod przesyłania plików bez kompresji, oba z lepszymi wynikami.

• 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.imgna odbiorniku i nc 192.168.161.62 5678 < vm1-root.imgnadajniku, 40 MB / s. Port 5678jest dowolnym, który był dostępny.

Używanie ncokazało się najszybszą metodą kopiowania!

W przeszłości scp -Cdziałało bardzo dobrze, ilekroć myślałem. Na przykład podczas przesyłania syslogs ( /var/log/messages*) o wielkości kilku GB. Nieskompresowana szybkość przesyłania wynosząca kilkaset KB / s wzrośnie do 1-2 MB / s. Ten przykład przypada w przypadku wolnego połączenia, jak wskazano na stronie podręcznika.

Mam przypadek, w którym nowo utworzony obraz dysku vdisk dla partycji 20 GB ma skompresowany rozmiar zaledwie 200 MB. Przy szybkości transferu około 25 MB / s kopiowanie byłoby możliwe w zaledwie 8 sekund zamiast ponad 13 minut! Oczywiście scpbez kompresji jest w tym przypadku nieefektywny, a scp -Cnawet gorzej.

Wydaje mi się, że główna lekcja, jakiej się tutaj nauczyłem, jest taka, że scp -Cnależy ją traktować jako wygodę. Jeśli plik można znacznie skompresować, lepiej najpierw skompresować go w źródle, przesłać skompresowaną formę i wreszcie skompresować w miejscu docelowym. Narzędzia, które szybko kompresują i dekompresują (np. Pbzip2 ), będą bardziej pomocne.

Cytowanie man ssh(które jest podstawą używaną przez scp):

Kompresja jest pożądana na liniach modemowych i innych powolnych połączeniach, ale spowolni tylko rzeczy w szybkich sieciach.

Problem polega na tym, że kompresja danych zajmuje więcej czasu niż przesłanie ich przez sieć.

Oprócz kompresji nc uzyskuje najlepszą szybkość, ponieważ nie szyfruje. Kompresja bezstratna polega na znalezieniu nadmiarowych sekcji danych, które po wykonaniu na poziomie sieci można sprawdzić maksymalnie w bajtach [wielkości bufora], a po pierwszym razem z całym plikiem - bajtów [wielkości pliku] w ramach którego można polować i chrupać zduplikowane zdania bajtowe.

Również do przenoszenia obrazów dysków należy użyć narzędzia obsługującego system plików, takiego jak ntfsclone / partclone, ponieważ nawet kompresja nie jest w stanie pokonać zwykłego pomijania nieprzydzielonych bloków - szybkość transferu jest nieskończona, jeśli nie trzeba przesyłać żadnych danych. Nie zapomnij także zniszczyć plików wymiany i hibernacji na partycji Windows, ponieważ kopiujesz śmieci, które po prostu wyrzucą i odtworzą.