Często zdarza mi się, że wysyłam foldery z 10 000 - 100 000 plików na zdalną maszynę (w tej samej sieci na terenie kampusu).

Zastanawiałem się tylko, czy istnieją powody, by w to wierzyć,

 tar + rsync + untar

Lub po prostu

 tar (from src to dest) + untar

może być szybszy w praktyce niż

rsync 

podczas przesyłania plików po raz pierwszy .

Interesuje mnie odpowiedź, która dotyczy powyższego w dwóch scenariuszach: przy użyciu kompresji i nieużywania jej.

Aktualizacja

Właśnie przeprowadziłem kilka eksperymentów przenoszących 10 000 małych plików (całkowity rozmiar = 50 MB) i tar+rsync+untarbyłem konsekwentnie szybszy niż uruchamianie rsyncbezpośrednio (oba bez kompresji).

Gdy wysyłasz ten sam zestaw plików, rsynclepiej nadaje się, ponieważ będzie wysyłał tylko różnice. tarzawsze wyśle ​​wszystko, a to jest marnotrawstwo zasobów, gdy wiele danych już tam jest. tar + rsync + untarTraci tę zaletę, w tym przypadku, jak również tę zaletę, utrzymując foldery w synchronizacji z rsync --delete.

Jeśli skopiujesz pliki po raz pierwszy, najpierw spakujesz, a następnie wyślesz, a następnie rozpakowanie (AFAIK rsyncnie pobiera danych z potoku) jest uciążliwe i zawsze gorsze niż tylko rsynchronizacja, ponieważ i rsynctak nie będziesz musiał wykonywać żadnych zadań tar.

Wskazówka: rsync w wersji 3 lub nowszej wykonuje przyrostową rekurencję, co oznacza, że ​​kopiowanie rozpoczyna się niemal natychmiast przed zliczeniem wszystkich plików.

Wskazówka 2: Jeśli użyjesz rsyncwięcej ssh, możesz również użyć jednego z nichtar+ssh

tar -C /src/dir -jcf - ./ | ssh user@server 'tar -C /dest/dir -jxf -'

Lub tylko scp

scp -Cr srcdir user@server:destdir

Ogólna zasada, nie krępuj się.

AKTUALIZACJA:

Stworzyłem 59M danych demo

mkdir tmp; cd tmp
for i in {1..5000}; do dd if=/dev/urandom of=file$i count=1 bs=10k; done

i kilkakrotnie przetestowałem transfer plików na zdalny serwer (nie w tym samym LAN), używając obu metod

time rsync -r  tmp server:tmp2

real    0m11.520s
user    0m0.940s
sys     0m0.472s

time (tar cf demo.tar tmp; rsync demo.tar server: ; ssh server 'tar xf demo.tar; rm demo.tar'; rm demo.tar)

real    0m15.026s
user    0m0.944s
sys     0m0.700s

zachowując osobne dzienniki od wysłanych pakietów ruchu ssh

wc -l rsync.log rsync+tar.log 
   36730 rsync.log
   37962 rsync+tar.log
   74692 total

W tym przypadku nie widzę żadnej korzyści w mniejszym ruchu w sieci przy użyciu rsync + tar, co jest oczekiwane, gdy domyślnym mtu jest 1500, a pliki mają rozmiar 10k. rsync + tar wygenerował większy ruch, działał wolniej przez 2-3 sekundy i pozostawił dwa pliki śmieci, które należało wyczyścić.

Zrobiłem te same testy na dwóch komputerach na tym samym LANie i tam rsync + tar wykonał znacznie lepsze czasy i znacznie mniejszy ruch sieciowy. Zakładam, że przyczyną są duże ramki.

Może rsync + tar byłoby lepsze niż rsync na znacznie większym zestawie danych. Ale szczerze mówiąc, nie sądzę, żeby to było warte kłopotu, potrzebujesz podwójnej przestrzeni z każdej strony do pakowania i rozpakowywania, a istnieje kilka innych opcji, jak już wspomniałem powyżej.

rsyncrównież kompresuje. Użyj -zflagi. Jeśli wybiegniesz ssh, możesz także użyć trybu kompresji ssh. Mam wrażenie, że powtarzane poziomy kompresji nie są przydatne; po prostu wypali cykle bez znaczącego rezultatu. Polecam eksperymentować z rsynckompresją. Wydaje się dość skuteczny. I sugerowałbym pominięcie użycia tarlub jakiejkolwiek innej kompresji przed / po.

Zwykle używam rsync jako rsync -abvz --partial....

Musiałem dziś wykonać kopię zapasową mojego katalogu domowego na NAS i zacząłem tę dyskusję, pomyślałem, że dodam swoje wyniki. Krótko mówiąc, tar'owanie przez sieć do docelowego systemu plików jest w moim środowisku znacznie szybsze niż rsynchronizacja do tego samego miejsca docelowego.

Środowisko: Komputer źródłowy i7 na komputerze stacjonarnym za pomocą dysku twardego SSD. Maszyna docelowa Synology NAS DS413j na gigabitowym połączeniu LAN z maszyną źródłową.

Dokładna specyfikacja tego zestawu wpłynie oczywiście na wydajność i nie znam szczegółów mojej dokładnej konfiguracji w odniesieniu do jakości sprzętu sieciowego na każdym końcu.

Pliki źródłowe to mój folder ~ / .cache, który zawiera 1,2 GB w większości bardzo małych plików.

1a/ tar files from source machine over the network to a .tar file on remote machine

$ tar cf /mnt/backup/cache.tar ~/.cache

1b/ untar that tar file on the remote machine itself

$ ssh admin@nas_box
[admin@nas_box] $ tar xf cache.tar

2/ rsync files from source machine over the network to remote machine

$ mkdir /mnt/backup/cachetest
$ rsync -ah .cache /mnt/backup/cachetest

Zachowałem 1a i 1b jako całkowicie oddzielne kroki tylko dla zilustrowania zadania. Dla praktycznych zastosowań poleciłbym to, co napisał Gilles powyżej, dotyczący przesyłania danych wyjściowych tar przez ssh do procesu rozpakowywania w odbiorniku.

Czasy:

1a - 33 seconds

1b - 1 minutes 48 seconds

2 - 22 minutes

Oczywiste jest, że rsync działał niezwykle słabo w porównaniu z operacją tar, co można przypuszczalnie przypisać zarówno wspomnianej powyżej wydajności sieci.

Polecam każdemu, kto chce wykonać kopię zapasową dużych ilości przeważnie małych plików, takich jak kopia zapasowa katalogu domowego, skorzystaj z metody tar. rsync wydaje się bardzo złym wyborem. Wrócę do tego postu, jeśli wydaje się, że byłem niedokładny w którejkolwiek z moich procedur.

Nacięcie

Użycie rsync do wysłania żądanego archiwum tar byłoby marnotrawstwem lub zasobami, ponieważ do procesu dodawano by warstwę weryfikacyjną. Rsync sprawdzałby sumę pliku tar pod kątem poprawności, gdy wolisz sprawdzać poszczególne pliki. (Nie pomaga wiedzieć, że plik tar, który mógł być wadliwy po stronie wysyłającej, wykazuje już ten sam efekt na końcu odbierającym). Jeśli wysyłasz archiwum, wystarczy ssh / scp.

Jednym z powodów, dla których mógłbyś wybrać wysyłanie archiwum, byłoby to, że wybrana przez ciebie tar była w stanie zachować więcej specjalizacji systemu plików, takich jak Lista Kontroli Dostępu lub inne Metadane często przechowywane w Rozszerzonych Atrybutach (Solaris) lub Ressource Forks (MacOS) ). Kiedy zajmujesz się takimi rzeczami, Twoim głównym zmartwieniem będzie to, które narzędzia są w stanie zachować wszystkie informacje związane z plikiem w źródłowym systemie plików, pod warunkiem, że docelowy system plików ma również możliwość ich śledzenia.

Kiedy najważniejsza jest prędkość, zależy ona w dużej mierze od rozmiaru twoich plików. Ogólnie rzecz biorąc, wiele małych plików będzie źle skalować się w stosunku do rsync lub scp, ponieważ wszystkie będą marnować poszczególne pakiety sieciowe, z których każdy plik tar zawiera kilka z nich w ramach obciążenia danych pojedynczego pakietu sieciowego. Nawet lepiej, jeśli plik tar zostanie skompresowany, ponieważ małe pliki najprawdopodobniej skompresują się lepiej jako całość niż osobno. O ile mi wiadomo, zarówno rsync, jak i scp nie optymalizują podczas wysyłania całych pojedynczych plików, jak w przypadku początkowego transferu, ponieważ każdy plik zajmuje całą ramkę danych z całym narzutem protokołu (i marnuje więcej na sprawdzanie w przód i w tył). Jednak Janecekstwierdza, że ​​jest to prawdą tylko w przypadku scp, z tą różnicą, że rsync zoptymalizuje ruch sieciowy, ale kosztem budowy ogromnych struktur danych w pamięci. Zobacz artykuł Efficient File Transfer, Janecek 2006 . Według niego nadal jest prawdą, że zarówno scp, jak i rsync źle skalują się na małych plikach, ale z zupełnie innych powodów. Chyba będę musiał zagłębić się w źródła w ten weekend, żeby się dowiedzieć.

Dla praktycznego znaczenia, jeśli wiesz, że wysyłasz głównie większe pliki, nie będzie dużej różnicy prędkości, a użycie rsync ma tę dodatkową zaletę, że może zająć miejsce, w którym zostało przerwane po przerwaniu.

Postscriptum: W dzisiejszych czasach rdist wydaje się zapadać w zapomnienie, ale przed dniami rsync było to bardzo sprawne narzędzie i szeroko stosowane (bezpiecznie, gdy używa się ssh, inaczej niebezpieczne). Nie działałbym tak dobrze jak rsync, ponieważ nie zoptymalizował się on tylko do przesyłania zmienionych treści. Zasadnicza różnica w stosunku do rsync polega na sposobie konfiguracji i na pisowni reguł aktualizacji plików.

W przypadku małych katalogów (małych jak na używanym miejscu na dysku) zależy to od narzutu związanego z sprawdzaniem informacji o plikach w celu synchronizacji plików. Z jednej strony rsyncoszczędza czas przesyłania niezmodyfikowanych plików, z drugiej strony rzeczywiście musi przesyłać informacje o każdym pliku.

Nie znam dokładnie wewnętrznych rsync. To, czy statystyki plików powodują opóźnienie, zależy od sposobu rsyncprzesyłania danych - jeśli statystyki plików są przesyłane jeden po drugim, RTT może przyspieszyć tar + rsync +.

Ale jeśli masz, powiedzmy 1 GiB danych, rsync będzie znacznie szybszy, no chyba, że ​​twoje połączenie jest naprawdę szybkie!

Musiałem przenieść kilka terabajtów danych w całym kraju, dokładnie raz. W ramach eksperymentu przeprowadziłem dwa transfery, używając rsynci, ssh/taraby zobaczyć, jak się porównują.

Wyniki:

• rsync przesyłane pliki ze średnią szybkością 2,76 megabajtów na sekundę.
• ssh/tar przesyłane pliki ze średnią prędkością 4,18 megabajtów na sekundę.

Szczegóły: Moje dane składają się z milionów skompresowanych plików .gz, których średni rozmiar to 10 megabajtów, ale niektóre mają ponad gigabajt. Istnieje struktura katalogów, ale jest ona mniejsza niż rozmiar danych w plikach. Gdybym miał prawie cokolwiek innego do zrobienia, skorzystałbym tylko, rsyncale w tym przypadku ssh/tarjest to funkcjonalne rozwiązanie.

Moja praca rsyncpolega na:

rsync --compress --stats --no-blocking-io --files-from=fileList.txt -av otherSystem:/the/other/dir/ dest/

gdzie fileList.txt to świetna długa lista względnych ścieżek plików po drugiej stronie. (Zauważyłem, że po uruchomieniu --compressnie jest to wydajne w przypadku plików skompresowanych, ale nie zamierzałem ponownie uruchamiać ponownie).

Zacząłem inny od ssh i tar, który ma:

ssh otherSystem "cd /the/other/dir/;  tar cf - ." | tar xvf -

Zobaczysz wszystkie te kopie, przepraszam, to nie jest porównanie w 100% jabłek do jabłek.

Powinienem dodać, że podczas korzystania z wewnętrznej sieci firmowej muszę przejść przez pośrednika, aby dostać się do komputera źródła danych. Czas pingowania z mojego komputera docelowego do pośrednika wynosi 21 ms, a od pośrednika do źródła danych - 26 ms. To samo dotyczy obu transferów.

Połączenie SSL przez pośrednika odbywa się poprzez ~/.ssh/configwpis:

Host otherSystem
    Hostname dataSource.otherSide.com
    User myUser
    Port 22
    ProxyCommand ssh -q -W %h:%p intermediary.otherSide.com
    IdentityFile   id_rsa.priv

Czas to:

tar cf - ~/.cache | ssh admin@nas_box "(cd /destination ; tar xf -)"