Dlaczego moja rsync jest taka wolna?


42

Mój laptop i moja stacja robocza są podłączone do przełącznika Gigabit. Oba działają pod Linuksem. Ale kiedy kopiuję pliki rsync, działa to źle.

Dostaję około 22 MB / s. Czy teoretycznie nie powinienem uzyskać około 125 MB / s? Jaki jest tutaj czynnik ograniczający?

EDYCJA: Przeprowadziłem kilka eksperymentów.

Napisz wydajność na laptopie

Laptop ma system plików XFS z pełnym szyfrowaniem dysku. Używa aes-cbc-essiv:sha256trybu szyfrowania o długości klucza 256 bitów. Wydajność zapisu na dysku wynosi 58,8 MB / s .

iblue@nerdpol:~$ LANG=C dd if=/dev/zero of=test.img bs=1M count=1024
1073741824 Bytes (1.1 GB) copied, 18.2735 s, 58.8 MB/s

Przeczytaj wyniki na stacji roboczej

Pliki, które skopiowałem, znajdują się na oprogramowaniu RAID-5 na 5 dyskach twardych. Na szczycie nalotu znajduje się lvm. Sam wolumin jest szyfrowany za pomocą tego samego szyfru. Stacja robocza ma procesor FX-8150 z natywnym zestawem instrukcji AES-NI, który przyspiesza szyfrowanie. Wydajność odczytu dysku wynosi 256 MB / s (pamięć podręczna była zimna).

iblue@raven:/mnt/bytemachine/imgs$ dd if=backup-1333796266.tar.bz2 of=/dev/null bs=1M
10213172008 bytes (10 GB) copied, 39.8882 s, 256 MB/s

Wydajność sieci

Uruchomiłem iperf między dwoma klientami. Wydajność sieci wynosi 939 Mbit / s

iblue@raven $ iperf -c 94.135.XXX
------------------------------------------------------------
Client connecting to 94.135.XXX, TCP port 5001
TCP window size: 23.2 KByte (default)
------------------------------------------------------------
[  3] local 94.135.XXX port 59385 connected with 94.135.YYY port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.09 GBytes   939 Mbits/sec

3
Protokół rsync: // czy tunelowanie przez SSH? W tym ostatnim są bardzo wyraźne ograniczenia wydajności ¹ .
ephemient

Odpowiedzi:


18

Innym sposobem na ograniczenie dużego zużycia procesora, ale utrzymanie funkcjonalności rsync, jest przejście z rsync / SSH na rsync / NFS. Możesz wyeksportować ścieżki, z których chcesz skopiować za pośrednictwem NFS, a następnie użyć lokalnie rsync z montowania NFS do lokalizacji docelowej.

W jednym teście z dysku sieciowego WD MyBook Live, jeden lub więcej rsyncsów z NAS w sieci Gigabit w kierunku 2 lokalnych dysków USB nie skopiowałoby więcej niż 10 MB / s (procesor: 80% usr, 20% sys), po wyeksportowaniu Lokalnie NFS i rsyncing z udziału NFS na oba dyski Mam w sumie 45 MB / s (maksymalnie oba dyski USB2) i niewielkie zużycie procesora. Wykorzystanie dysku podczas korzystania z rsync / SSH wyniosło około 6%, a użycie rsync / NFS było bliższe 24%, podczas gdy oba dyski USB2 były blisko 100%.

Dlatego skutecznie przenieśliśmy wąskie gardło z procesora NAS na oba dyski USB2.


4
Ostrzegamy jednak, że NFS nie oferuje bezpieczeństwa (tj. Szyfrowania).
WhyNotHugo

To działało świetnie! Teraz osiągam prawie pełne prędkości gigabitowe, kiedy wcześniej uzyskiwałem ~ 100 Mb / s.
PHLAK

1
Czy możesz wskazać, jak korzystać z rsync / NFS? Usiłuję przenieść 8 TB między 2 dyskami MyCloud i trwa rsync przez ssh (4 MB / s)
FMaz008

26

Powody mogą obejmować: kompresję, szyfrowanie, liczbę i rozmiar kopiowanych plików, możliwości wejścia / wyjścia dysku systemu źródłowego i docelowego, obciążenie TCP ... To wszystko czynniki mogą wpływać na rodzaj przeprowadzanego transferu.

Opublikuj komendę rsync, której używasz, i podaj szczegółowe informacje na temat specyfikacji obu komputerów.


Edycja: Szyfrowanie jest często czynnikiem ograniczającym szybkość rsync. Możesz uruchomić z ssh i lżejszym szyfrem szyfrującymarcfour

Coś jak: rsync -e "ssh -c arcfour"

Lub możesz użyć zmodyfikowanego rsync / ssh, który może wyłączyć szyfrowanie. Zobacz hpn-ssh: http://psc.edu/networking/projects/hpn-ssh

Ale znowu, twój laptop ma wolny dysk w porównaniu ze stacją roboczą. Zapisy mogą być blokowane i czekają na wejście / wyjście do twojego laptopa. Jakie są twoje prawdziwe oczekiwania dotyczące wydajności?


1
Laptopy często mają wolniejsze dyski (7200 obr / min - 5400 obr / min), ponieważ zużywają mniej energii. Może to łatwo stanowić czynnik ograniczający w zależności od tego, co dokładnie robi rsync.
Ladadadada,

1
dzięki. Ponieważ rsyncningz zaszyfrowanego dysku dm-crypt podłączonego do procesora atomu do skrzynki ARM NAS ecryptfs , to zmieniło moją prędkość transferu z 4 Mb / s na 6 Mb / s. rsync --protocol=29 -auh --progress /mnt/esata/pics/ -e "ssh -c arcfour" diskstation:/volume1/picsLepsze niż nic.
Sebastian

Ta odpowiedź Przejście z rsync -azP na rsync -aPe „ssh -c arcfour” zwiększyło prędkość transferu z 4 MB / s do 25 MB / s między dwoma dyskami MyCloud Mirror. Procesor jednostki odbierającej jest teraz maksymalnie wykorzystany. (myślę, że to oznacza, że ​​przesyłam tak szybko, jak urządzenie może zapisywać dane)
FMaz008

10

Po kilku testach w końcu sam znalazłem odpowiedź. rsyncdomyślnie używa tunelowania przez ssh. Krypto spowalnia. Musiałem więc obejść te kryptograficzne rzeczy.

Rozwiązanie 1: Konfigurowanie serwera rsync

Aby użyć go za pomocą rsyncprotokołu, musisz skonfigurować serwer rsyncd. Na /etc/init.d/rsyncmoim laptopie był skrypt, więc zgadłem, że rsyncd działa. Myliłem się. /etc/init.d/rsync startistnieje po cichu, gdy rsync nie jest włączony w /etc/default/rsync. Następnie musisz go również skonfigurować /etc/rsyncd.conf, co jest uciążliwe.

Jeśli wszystko to zrobisz, musisz użyć rsync file.foo user@machine::directory. Pamiętaj, że są dwa dwukropki .

Rozwiązanie 2: Old-school rsh-server

Jednak konfiguracja była dla mnie zbyt skomplikowana. Właśnie zainstalowałem i rsh-serverna moim laptopie. Wywołanie rsync na stacji roboczej -e rexecużywa wtedy rsh zamiast ssh. Co następnie prawie podwoiło wydajność do 44,6 MB / s , co wciąż jest wolne. Prędkość odbija się od 58 MB / s do 33 MB / s , co oznacza, że ​​mogą występować problemy z buforowaniem lub kontrolą przeciążenia. Ale to wykracza poza zakres tego pytania.


2
Używamy tutaj rsync i zazwyczaj uzyskujemy pełną prędkość interfejsu, chyba że przemierzamy miliony plików 4K. Nie sądzę, że krypto stanowi problem, chyba że używasz poważnie zniszczonego sprzętu.
Magellan,

Czy Intel Core2 Duo T8100 w ThinkPad R61 jest liczony jako poważnie zniszczony sprzęt? Jeśli nie, to dlaczego rsync over ssh jest wolniejszy niż rsync over rsh?
iblue

5
Szyfrowanie jest często czynnikiem ograniczającym szybkość rsync wraz z liczbą plików. Standardowe metody poprawy tego stanu polegają na uruchomieniu rsync z mniejszym szyfrowaniem rsync -e "ssh -c arcfour"lub próbowaniu zmodyfikowanego rsync / ssh, który może wyłączyć szyfrowanie. Zobacz hpn-ssh: psc.edu/networking/projects/hpn-ssh
ewwhite

2

Są to bardzo stare pytania i odpowiedzi, ale brakuje jednej ważnej rzeczy: jeśli kopiujesz już skompresowane lub zaszyfrowane dane, wyłącz kompresję.

Jeśli Twoje dane nie są skompresowane ani zaszyfrowane, nadal chcesz je skompresować tylko raz! Rsync kompresuje za pomocą -z, ssh kompresuje za pomocą -C (może być domyślnie). Nie testowałem, co jest lepsze, ponieważ moje dane są skompresowane.

W tym momencie możesz wyłączyć przekazywanie X i przydzielanie TTY, co powoduje:

rsync -avh -e "ssh -x -T -c arcfour -o Compression=no" $src $dst

Na koniec upewnij się (na przykład za pomocą iptraf), że faktycznie używasz interfejsu sieciowego, którego według Ciebie używasz. Ku mojemu wielkiemu zdziwieniu zauważyłem, że na moim OSX wychodzące ssh wiązało się z adresem IP na domyślnym interfejsie wychodzącym, a nie z adresem IP interfejsu, na którym miały być kierowane pakiety. Moje bezpośrednie połączenie GB między dwoma laptopami również połączonymi przez WiFi nie było używane. Po badaniu było to spowodowane użyciem 169.254 / 16, które Mac umieszcza na wszystkich interfejsach, oraz komputerem docelowym odpowiadającym na żądania ARP, mimo że żądanie pojawiło się w innym interfejsie.


Prawidłowe opcje, ale uważam, że kompresja -x -T i -o = nie tylko miała niewielki wpływ na szybkość transferu.
FMaz008,

4
Warto również wspomnieć, że OpenSSH 6.7 wyłącza arcfour.
bparker

To trochę szkoda @bparker! Czy wiemy, który z pozostałych dostępnych szyfrów jest najlżejszy na procesorze?
Ustawa 29
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.