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+untar
byłem konsekwentnie szybszy niż uruchamianie rsync
bezpośrednio (oba bez kompresji).
tar cf - . | ssh remotehost 'cd /target/dir && tar xf -'
Odpowiedzi:
Gdy wysyłasz ten sam zestaw plików,
rsync
lepiej nadaje się, ponieważ będzie wysyłał tylko różnice.tar
zawsze wyśle wszystko, a to jest marnotrawstwo zasobów, gdy wiele danych już tam jest.tar + rsync + untar
Traci tę zaletę, w tym przypadku, jak również tę zaletę, utrzymując foldery w synchronizacji zrsync --delete
.Jeśli skopiujesz pliki po raz pierwszy, najpierw spakujesz, a następnie wyślesz, a następnie rozpakowanie (AFAIK
rsync
nie pobiera danych z potoku) jest uciążliwe i zawsze gorsze niż tylko rsynchronizacja, ponieważ irsync
tak 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
rsync
więcejssh
, możesz również użyć jednego z nichtar+ssh
Lub tylko
scp
Ogólna zasada, nie krępuj się.
AKTUALIZACJA:
Stworzyłem 59M danych demo
i kilkakrotnie przetestowałem transfer plików na zdalny serwer (nie w tym samym LAN), używając obu metod
zachowując osobne dzienniki od wysłanych pakietów ruchu ssh
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.
źródło
rsync
;)z
z rsync, kompresuje połączenie. Przy obecnej mocy procesora kompresja jest trywialna w porównaniu do zaoszczędzonej przepustowości, która może wynosić ~ 1/10 nieskompresowanych plików tekstowychrsync
również kompresuje. Użyj-z
flagi. Jeśli wybiegnieszssh
, 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ć zrsync
kompresją. Wydaje się dość skuteczny. I sugerowałbym pominięcie użyciatar
lub jakiejkolwiek innej kompresji przed / po.Zwykle używam rsync jako
rsync -abvz --partial...
.źródło
rsync
domyślnie pomija kompresję plików z pewnymi przyrostkami, w tym.gz
i.tgz
i innymi; poszukaj pełnejrsync
strony na stronie--skip-compress
podręcznika.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.
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:
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
źródło
-z
rsync do kompresji ten test wydaje się niepełny.z
argumentu, tak jak go użyłem, nie kompresuje danych (patrz unix.stackexchange.com/questions/127169/... ), o ile widzę używanie rsync bez kompresji, to uczciwe porównanie. Gdybym przekazywał wyjście tar przez bibliotekę kompresji, taką jak bzip2 lub gzip, wtedy tak,-z
byłoby rozsądne.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.
źródło
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
rsync
oszczę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 sposobursync
przesył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!
źródło
Musiałem przenieść kilka terabajtów danych w całym kraju, dokładnie raz. W ramach eksperymentu przeprowadziłem dwa transfery, używając
rsync
i,ssh/tar
aby 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,
rsync
ale w tym przypadkussh/tar
jest to funkcjonalne rozwiązanie.Moja praca
rsync
polega na:gdzie fileList.txt to świetna długa lista względnych ścieżek plików po drugiej stronie. (Zauważyłem, że po uruchomieniu
--compress
nie 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:
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/config
wpis:źródło
Czas to:
źródło