Czy istnieje szybsza alternatywa dla cp do kopiowania dużych plików (~ 20 GB)?

% CPU powinno być niskie podczas kopiowania. CPU mówi kontrolerowi dysku „pobierz dane z sektorów X – Y do bufora pamięci w Z”. Potem idzie i robi coś innego (lub śpi, jeśli nie ma nic innego). Sprzęt wyzwala przerwanie, gdy dane są w pamięci. Następnie procesor musi go kilka razy skopiować i nakazuje karcie sieciowej „transmitować pakiety w lokalizacjach pamięci A, B i C”. Potem wraca do robienia czegoś innego.

Przepychasz ~ 240 Mb / s.W gigabitowej sieci LAN powinieneś być w stanie osiągnąć co najmniej 800 Mb / s, ale:

1. To jest wspólne dla wszystkich użytkowników serwera plików (i prawdopodobnie połączenia między przełącznikami itp.)
2. To jest ograniczone przez szybkość, z jaką serwer plików może obsłużyć zapis, mając na uwadze, że przepustowość dysku we / wy jest współdzielona przez wszystkich, którzy go używają.
3. Nie określono uzyskujesz dostęp do serwera plików (NFS, CIFS (Samba), AFS itp.). Konieczne może być dostrojenie montowania sieci, ale we wszystkim, co jest w połowie niedawne, ustawienia domyślne są zwykle całkiem rozsądne.

Aby wyśledzić wąskie gardło, iostat -kx 10 będzie użytecznym poleceniem. Pokaże ci wykorzystanie lokalnych dysków twardych. Jeśli możesz to uruchomić na serwerze plików, pokaże ci, jak zajęty jest serwer plików.

Ogólnym rozwiązaniem będzie przyspieszyć to wąskie gardło, na które oczywiście nie masz budżetu. Jest jednak kilka specjalnych przypadków, w których można znaleźć szybsze podejście:

• Jeśli pliki można kompresować, i masz szybki procesor, wykonanie minimalnego kompresji w locie może być szybsze. Na przykład lzop lub może gzip --fastest.
• Jeśli zmieniasz tylko kilka bitów tu i tam, a następnie wysyłasz plik z powrotem, tylko wysyłanie delt będzie znacznie szybsze. Niestety, rsync nie pomoże tutaj, ponieważ będzie musiał przeczytać plik po obu stronach, aby znaleźć deltę. Zamiast tego potrzebujesz czegoś, co śledzi deltę podczas zmiany pliku … Większość podejść tutaj jest specyficznych dla aplikacji. Ale jest możliwe, że możesz coś skonfigurować za pomocą, np. Device-mapper (zobacz zupełnie nowy cel dm-era ) lub btrfs.
• Jeśli kopiujesz te same dane do wielu maszyn, możesz użyć czegoś takiego jak udpcast, aby wysłać je do wszystkich maszyn naraz.

I, ponieważ zauważyłeś, że nie jesteś administratorem systemu, zgaduję, że masz administratora systemu. Albo przynajmniej kogoś odpowiedzialnego za sieć & serwera plików. Prawdopodobnie powinieneś zapytać go / jej / ich, powinni być znacznie lepiej zaznajomieni ze specyfiką Twojej konfiguracji. Twój administrator systemu powinien przynajmniej być w stanie powiedzieć Ci, jakiej szybkości transferu możesz się spodziewać.

Komentarze

• +1 dla iostat -kx 10 🙂

Prawdopodobnie może to być szybsza alternatywa i nie zatykasz sieci przez dwa dni: weź jeden lub dwa duże dyski USB (USB 3, jeśli je masz) lub FireWire, podłącz je do serwer i skopiuj pliki na dysk. Przenieś dysk na komputer lokalny. Skopiuj pliki na komputer.

Komentarze

• Sneakernet ( en.wikipedia.org/ wiki / Sneakernet ) może być bardzo szybki: nigdy nie lekceważ przepustowości wagonu kombi pełnego taśm pędzących autostradą.

Jeśli masz bezpośredni dostęp SSH (lub SFTP) (zapytaj swojego administratora), możesz użyć scp z kompresją (-C):

scp -C you@server:/path/to/yourfile . 

Oczywiście jest to przydatne tylko wtedy, gdy plik jest kompresowalny i zużywa więcej czasu procesora, ponieważ będzie używać szyfrowania (ponieważ odbywa się za pośrednictwem protokołu SSH) i kompresji.

Komentarze

• W tym przypadku przydatne byłoby wyłączenie szyfrowanie. Pamiętaj, że staramy się, aby kopia była szybsza .
• @lgeorget Podejrzewam, że narzut szyfrowania wygrał ' nie był znaczący biorąc pod uwagę, jak wolne są dyski twarde. Rozważałem dodanie czegoś o -c none, ale to wydaje się być niestandardowe .
• ' mamy do czynienia z plikami ~ 20G, więc jest dość nieefektywne użycie szyfrowania, jeśli nie jest potrzebne.
• @lgeorget Szyfrowanie może być wykonano znacznie szybciej niż przepustowość, którą ' uzyskuje, więc nie ' nic nie spowolni. Ale przechodzenie przez SSH tutaj wydaje się niepotrzebne. Jeśli potrzebujesz tylko kompresji, na pewno istnieją inne narzędzia?
• @Thomas Zaletą SSH jest to, że jeśli ' masz mieć dostęp do zdalnego serwera, to ' prawie na pewno działa przez SSH. Inną opcją byłoby skompresowanie pliku lokalnie, skopiowanie go na serwer, a następnie ssh in i zdekompresowanie.

Twoja definicja wydajności jest wsteczna. Bardziej wydajne wdrożenie marnuje mniej czasu procesora. Na lokalnej kopii masz średnio około 74 MB / s przepustowości (odczyt + zapis), czyli mniej więcej tyle, ile osiąga pojedynczy dysk twardy.

Komentarze

• Ups.Kiedy powiedziałem ” wydajnie, ” miałem na myśli ” szybko. ”

cp wdrożenie najprawdopodobniej nie jest wąskim gardłem. Spróbuj obserwować użycie we / wy za pośrednictwem iotop na serwerze i węźle klastra. To da ci pomysł, gdzie możesz poprawić wydajność.

Kolejną wskazówką jest unikanie kopiowania tych samych danych z tego samego hosta. Na przykład, jeśli masz identyczny plik 20G do dystrybucji z serwera plików przez sieć do wszystkich węzłów klastra, będzie działać znacznie szybciej, jeśli kopiujesz pliki w trybie peer-to-peer, a nie jeden serwer do wszystkich klientów. Jest to trochę bardziej skomplikowane w implementacji, ale możesz nawet spróbować użyć jakiegoś p2p wiersza poleceń, takiego jak koncentrator bezpośredniego połączenia.

Jeśli w tych plikach 20G część jest wspólna, a niektóre są specyficzne dla węzła klastra, rozważ dzielenie go na wspólne i określone części, a następnie rozpowszechnianie części wspólnej w sposób p2p.

Komentarze

• Jeśli ' jeśli jesteś w sieci LAN, powinieneś być w stanie wykonać multiemisję zamiast peer-to-peer. Co powinno być szybsze i mniej obciążające sieć.

Natura / zawartość tych plików może mieć znaczenie. Zrozumiałem, że musisz skopiować 200 plików, po ~ 20 GB każdy, z jednego komputera na drugi Czy to wszystko?

Jeśli te pliki są kompresowalne lub mają podobne / identyczne elementy, masz dwie możliwości:

• spakuj je przed skopiowaniem lub utwórz tunel między komputerami z włączonym zipem. Jeśli więc sieć jest wąskim gardłem, będzie trochę szybko r

• jeśli pliki są bardzo podobne lub mają kilka wspólnych elementów, spróbuj użyć rsync . Spędza trochę czasu na znajdowaniu tego, co jest wspólne dla plików, i nie będzie potrzeby kopiowania tego dosłownie , ponieważ zrekonstruuje to na podstawie tego, co jest powszechne.

edytuj

Czy będziesz musiał kopiować te pliki wiele razy ?? (jak kopia -> użyj tych plików -> zmień coś w plikach w komputerze A -> skopiuj pliki ponownie na komputer B)

Jeśli tak, rsync będzie pomocny, ponieważ spróbuje wykryć, co jest równe między wersjami i nie kopiuje tego, co jest niezmienione.

I trzecia metoda: jeśli powyższe jest poprawne (zmiany w pliku, a następnie skopiuj wszystkie pliki ponownie na drugi komputer), możesz spróbować binary diff, aby po prostu zmienić na drugim komputerze, co zostało zmienione na pierwszym komputerze.

Widzę tutaj, że szyfrowanie nie jest dobry pomysł, ponieważ może to prawdopodobnie ZWIĘKSZYĆ ilość danych do przesłania.

Jeśli kopiujesz między dwoma systemami, wąskim gardłem jest oczywiście t Połączenie między serwerami.

Jeśli kopiujesz lokalnie, spójrz, jak przebiega ten proces, jest to POJEDYNCZY wątek, dlatego standardowe narzędzia Linuksa używają:

- for all blocks in a file read a block write a block 

NIE ma współbieżności w tej operacji.

Aby przyspieszyć działanie, możesz użyć czegoś takiego:

 buffer -i infile -o outfile -m size-of-shared-memory-default-1MByte 

Więcej informacji znajdziesz na stronie podręcznika buffer (1).

Polecenie buffer konfiguruje dwa procesy do jednoczesnego uruchamiania procesu kopiowania: jeden do odczytu, a drugi do zapisu, i używa bufora pamięci współdzielonej do przesyłania danych między dwoma procesami. Bufor pamięci współdzielonej to klasyczny bufor cykliczny, który zapobiega nadpisywaniu niepisanych danych i zapisywaniu danych już zapisanych. Użyłem tego programu, aby odciąć około 10-20% czasu kopiowania podczas transferu z dysku na taśmę.

Komentarze

• Właściwie jest współbieżność w ” przeczytaj blok / napisz blok „, ponieważ ” napisz blok ” po prostu umieszcza go w buforze jądra ', a jądro obsługuje rzeczywisty blok zapisu w tle (przynajmniej do momentu zaczyna brakować pamięci RAM). Lub jeśli z jakiegoś powodu używasz O_DSYNC / O_SYNC.

Dlaczego nie wypróbować algorytmu propagacji P2P , jeśli chcesz zaktualizować cały klaster w tym samym czasie?

https://github.com/lg/murder to czego używa twitter

Jest BTSync , którego możesz również wypróbować.

Jeśli często kopiujesz te same zestawy plików z komputera lokalnego na serwer z niewielkimi zmianami tu i tam. Możesz przyspieszyć transfer za pomocą rsync lub DVCS (np. Hg lub git).

git lub hg mogą śledzić i wykrywać delty i przenosić tylko te delty. W przypadku korzystania z gita, ponieważ obie strony mają pełną historię repozytorium, ustalenie delty jest bardzo tanie.

rsync używa algorytmu kroczącej sumy kontrolnej do wykrywania delt bez wcześniejszej wiedzy o tym, co jest po drugiej stronie. Rsync potrzebuje więcej pracy, aby obliczyć delty, ale nie musi przechowywać całości historia plików.

Możesz spróbować spakować wszystkie pliki do jednego archiwum (nie trzeba go kompresować). Z mojego doświadczenia wynika, że kopiowanie tego jednego archiwum jest szybsze niż kopiowanie dużej liczby pojedynczych plików

Komentarze

• Dobra ogólna obserwacja, ale jak mówi pytanie „~ 200 dużych plików – każdy ~ 20 GB”, nie ' nie wierzę, że można to uznać za rzeczywistą odpowiedź na ten problem.
• @manatwork ah .. ja nie ' nie czytałem wyraźnie. Myślałem, że ma 200 plików o łącznej wielkości 20 GB.

Wypróbuj bbcp . Testy w naszym środowisku wykazały, że cp ma jakiś rodzaj f wbudowany w zarządcę. Po prostu bądź ostrożny, ponieważ kiedy zdejmiesz zarządcę, możesz zablokować swój serwer i spowodować awarię. W naszym przypadku wyłączaliśmy serwer, aby wykonać kopię, więc szybsze było lepsze. To poprawiło czas przesyłania o kilka godzin.

Upewnij się, że miejsce docelowe pliki nie istnieją przed skopiowaniem.

Czasami zaskakujące jest, ile czasu spędza się nawet na kopiowaniu na tym samym hoście (bez sieci).

Zobacz moją odpowiedź na inne pytanie cp tutaj . Krótko mówiąc, nadpisanie istniejącego pliku jest znacznie wolniejsze niż jego najpierw obcinanie lub odłączanie, a następnie kopiowanie. To drugie jest 8x szybsze dla pliku 1,2 GB.