Dlaczego rsync jest szybszy niż NFS?

Kilka dni temu zauważyłem coś raczej dziwnego (przynajmniej dla mnie). Uruchomiłem rsync, kopiując te same dane i usuwając je później na mount NFS, o nazwie /nfs_mount/TEST. To /nfs_mount/TESTjest hostowane / eksportowane z nfs_server-eth1. MTU na obu interfejsach sieciowych wynosi 9000, przełączanie między obsługuje także ramki jumbo. Jeśli to zrobię rsync -av dir /nfs_mount/TEST/, uzyskam prędkość transferu sieciowego X MB / s. Jeśli to zrobię rsync -av dir nfs_server-eth1:/nfs_mount/TEST/, uzyskam prędkość transferu sieciowego co najmniej 2X MBps. Moje opcje montowania NFS są nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp.

Konkluzja: oba transfery przechodzą przez tę samą podsieć sieci, te same przewody, te same interfejsy, odczytują te same dane, zapisują w tym samym katalogu itp. Jedyną różnicą jest jedna przez NFSv3, druga przez rsync.

Klientem jest Ubuntu 10.04, serwer Ubuntu 9.10.

Dlaczego rsync jest znacznie szybszy? Jak dopasować NFS do tej prędkości?

Dzięki

Edycja: pamiętaj, że używam rsync do pisania w udziale NFS lub SSH na serwerze NFS i pisz tam lokalnie. Za każdym razem robię rsync -av, zaczynając od czystego katalogu docelowego. Jutro spróbuję z zwykłą kopią.

Edycja2 (dodatkowe informacje): Rozmiar pliku wynosi od 1 KB do 15 MB. Pliki są już skompresowane, próbowałem je skompresować bez powodzenia. Zrobiłem tar.gzz tego plik dir. Oto wzór:

• rsync -av dir /nfs_mount/TEST/ = najwolniejszy transfer;
• rsync -av dir nfs_server-eth1:/nfs_mount/TEST/= najszybszy rsync z włączonymi ramkami jumbo; bez dużych ramek jest nieco wolniejszy, ale wciąż znacznie szybszy niż ten bezpośrednio do NFS;
• rsync -av dir.tar.gz nfs_server-eth1:/nfs_mount/TEST/ = mniej więcej tyle samo, co jego odpowiednik inny niż tar.gz;

Testy z cpi scp:

• cp -r dir /nfs_mount/TEST/= nieco szybciej niż, rsync -av dir /nfs_mount/TEST/ale nadal znacznie wolniej niż rsync -av dir nfs_server-eth1:/nfs_mount/TEST/.
• scp -r dir /nfs_mount/TEST/= ogólnie najszybszy, nieznacznie pokonuje rsync -av dir nfs_server-eth1:/nfs_mount/TEST/;
• scp -r dir.tar.gz /nfs_mount/TEST/ = mniej więcej tyle samo, co jego odpowiednik inny niż tar.gz;

Wniosek oparty na tych wynikach: w tym teście nie ma znaczącej różnicy, jeśli używasz dużego pliku tar.gz lub wielu małych. Włączanie i wyłączanie ramek Jumbo również nie robi prawie żadnej różnicy. cpi scpsą szybsze niż ich odpowiedniki rsync -av. Zapis bezpośrednio do wyeksportowanego udziału NFS jest znacznie wolniejszy (co najmniej 2 razy) niż zapis do tego samego katalogu przez SSH, niezależnie od zastosowanej metody.

Różnice między cpi rsyncw tym przypadku nie są istotne. Postanowiłem spróbować cpi scppo prostu zobaczyć, czy pokazują ten sam wzór i robią - 2X różnicy.

Kiedy używam rsynclub cpw obu przypadkach, nie rozumiem, co uniemożliwia NFS osiągnięcie prędkości przesyłania tych samych poleceń przez SSH.

Dlaczego pisanie do udziału NFS jest 2 razy wolniejsze niż pisanie w tym samym miejscu przez SSH?

Edit3 (NFS server / etc / eksport opcje): rw,no_root_squash,no_subtree_check,sync. Klienta / proc / mounts pokazuje: nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp.

Dziękuję wam wszystkim!

Może nie jest to wolniejsza prędkość przesyłania, ale zwiększone opóźnienie zapisu. Spróbuj zamontować asynchroniczny udział NFS zamiast zsynchronizować i sprawdź, czy to zamknie różnicę prędkości. Kiedy rsync przez ssh, zdalny proces rsync zapisuje asynchronicznie (szybko). Ale podczas zapisu do synchronicznie zamontowanego udziału NFS zapisy nie są natychmiast potwierdzane: serwer NFS czeka, aż trafi na dysk (lub bardziej prawdopodobne, pamięć podręczna kontrolera), zanim wyśle ​​potwierdzenie do klienta NFS, że zapis się powiódł.

Jeśli „asynchronizacja” rozwiązuje problem, pamiętaj, że jeśli coś się stanie z serwerem NFS w trakcie zapisu, bardzo dobrze możesz skończyć z niespójnymi danymi na dysku. Dopóki to podłączenie NFS nie jest podstawową pamięcią dla tych (lub innych) danych, prawdopodobnie nic ci nie będzie. Oczywiście byłbyś w tej samej łodzi, gdybyś wyciągnął wtyczkę z serwera nfs podczas / po uruchomieniu rsync-over-ssh (np. Rsync powraca po zakończeniu, serwer nfs ulega awarii, nieprzypisane dane w pamięci podręcznej zapisu są teraz tracone pozostawiając niespójne dane na dysku).

Chociaż nie jest to problem z testem (rsynchronizacja nowych danych), należy pamiętać, że rsync przez ssh może powodować znaczne wymagania procesora i IO na zdalnym serwerze, zanim pojedynczy bajt zostanie przesłany podczas obliczania sum kontrolnych i generowania listy plików, które muszą być zaktualizowane.

NFS jest protokołem udostępniania, a Rsync jest zoptymalizowany do przesyłania plików; istnieje wiele optymalizacji, które można wykonać, gdy z góry wiadomo, że Twoim celem jest jak najszybsze kopiowanie plików zamiast udostępniania ich wspólnego dostępu.

To powinno pomóc: http://en.wikipedia.org/wiki/Rsync

Rsync to protokół plików, który przenosi tylko zmienione bity między plikami. NFS to zdalny protokół plików katalogowych, który obsługuje wszystko za każdym razem ... w pewnym sensie jak SMB. Oba są różne i do różnych celów. Możesz użyć Rsync do transferu między dwoma udziałami NFS.

To jest interesujące. Możliwością, której mogłeś nie wziąć pod uwagę, jest zawartość / typ przesyłanego pliku.

Jeśli masz małe pliki (np. E-maile w pojedynczych plikach), wydajność NFS może być duża, ponieważ nie używasz pełnej MTU (być może jest to jednak mniej prawdopodobne w przypadku TCP przez UDP).

Alternatywnie, jeśli masz wysoce kompresowalne pliki / dane, szybkie procesory i sieć, która nie ma dość dużej szybkości procesora (*), możesz uzyskać przyspieszenie tylko z niejawnej kompresji za pośrednictwem łącza ssh.

Trzecią możliwością jest to, że pliki (lub jedna ich wersja) już istnieją w miejscu docelowym. W takim przypadku przyspieszenie byłoby spowodowane tym, że protokół rsync oszczędza przesyłanie plików.

(*) W tym przypadku „szybkość” odnosi się do szybkości, z jaką procesor może kompresować dane, w porównaniu do szybkości, z jaką sieć może przesyłać dane, np. Przesłanie 5 MB przez przewód zajmuje 5 sekund, ale procesor może skompresować te 5 MB do 1 MB w ciągu 1 sekundy. W takim przypadku czas transmisji skompresowanych danych wynosiłby nieco ponad 1 sekundę, podczas gdy nieskompresowane dane wynoszą 5 sekund.

Używam również -e „ssh Ciphers = arcfour”, aby zwiększyć przepustowość.

jeśli Twoim celem jest po prostu skopiowanie wszystkich plików z jednego miejsca do drugiego, wtedy tar / netcat będzie najszybszą opcją. jeśli wiesz, że w twoich plikach jest dużo białych znaków (zer), użyj opcji -i.

ŹRÓDŁO: tar cvif - / path / to / source | nc CEL PORTNUM CEL: cd / path / to / source && nc -l PORTNUM | tar xvif -

jeśli wiesz, że twoje dane są kompresowalne, użyj kompresji w poleceniach tar -z -j -Ipixz

Jestem fanem pixz .. równoległego xz, oferuje świetną kompresję i mogę dostroić liczbę procesorów, jakie mam do przepustowości sieci. jeśli mam wolniejsze pasmo, użyję wyższej kompresji, więc czekam na CPU więcej niż sieć .. jeśli mam szybką sieć, użyję bardzo niskiej kompresji:

ŹRÓDŁO: tar cvif - / path / to / source | pixz -2 -p12 | nc PORTNUM CELU # tar, ignoruj ​​zera, kompresja pixz poziomu 2 przy użyciu 12 rdzeni procesora CEL: nc -l PORTNUM | tar -Ipixz -xvif

jeśli odpowiednio dostosujesz poziom kompresji i rdzenie, w zależności od zestawu danych, powinieneś być w stanie utrzymać sieć w pobliżu nasycenia i wykonać wystarczającą kompresję, wąskie gardło staje się dyskiem (zwykle stroną do zapisu, jeśli systemy dysków do odczytu i zapisu są to samo).

podobnie jak w przypadku rsync, uważam, że pomija zera podobnie jak tar z tą opcją, więc przesyła mniej danych niż NFS. NFS nie może przyjmować założeń dotyczących danych, dlatego musi przesyłać każdy bajt wraz z narzutem protokołu NFS. rsync ma pewne narzuty ..

Netcat w zasadzie nie ma żadnego ... wyśle ​​pełne pakiety TCP, które zawierają tylko ważne dane.

z netcat, podobnie jak z scp, musisz cały czas wysyłać wszystkie dane źródłowe, nie możesz być wybiórczy, jak z rsync, więc nie nadaje się do przyrostowych kopii zapasowych itp., ale jest dobry do kopiowania danych lub archiwizacji.

Czy masz skonfigurowane blokowanie plików w NFSShare? Możesz uzyskać znacznie większą wydajność, jeśli zostanie ona wyłączona.

Zakładam, że zwiększona prędkość jest przynajmniej częściowo spowodowana tym, że „rsync src host: / path” spawnuje lokalny proces na zdalnej maszynie do wysyłania / odbierania, skutecznie zmniejszając twoje I / O o połowę.