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


40

Jestem doktorantem, a grupa, w której pracuję, utrzymuje klaster Linux. Każdy węzeł klastra ma własny dysk lokalny, ale dyski lokalne są stosunkowo małe i nie są wyposażone w automatyczne tworzenie kopii zapasowych. Tak więc grupa posiada serwer plików z wieloma TB przestrzeni dyskowej. Jestem względnym nowicjuszem w systemie Linux, więc nie jestem pewien, jakie są specyfikacje serwera plików pod względem szybkości, możliwości pracy w sieci itp. Z doświadczenia wiem, że dyski lokalne są znacznie szybsze niż serwer plików pod względem operacji we / wy . Z serwera plików korzysta około tuzina osób.

Korzystanie cpskopiować ~ 20 GB plik z serwera plików do jednej z lokalnych dysków trwa około 11,5 minuty w czasie rzeczywistym na średni (zgodnie time). Wiem, że ta cpoperacja nie jest bardzo wydajna, ponieważ (1) timemówi mi, że czas systemowy dla takiej kopii wynosi tylko ~ 45 sekund; a ponieważ (2) podczas sprawdzania toppodczas kopiowania % procesora jest dość niski (według kontroli średnio około 0-10% ).

Korzystanie cpskopiowanie tego samego ~ 20 PL plik z jednym katalogu na dysku lokalnego na inny katalogu na tym samym dysku lokalnego zajmuje mniej czasu - około 9 minut, w czasie rzeczywistym (~ 51 sekund, w czasie, w zależności od systemu time). Najwyraźniej serwer plików jest zgodnie z oczekiwaniami nieco wolniejszy niż dysk lokalny, ale być może nie jest znacznie wolniejszy. Dziwi mnie, że kopiowanie z lokalnego na ten sam lokalny nie trwa krócej niż 9 minut.

Muszę skopiować ~ 200 dużych plików - każdy ~ 20 GB - z serwera plików na jeden z dysków lokalnych. Moje pytanie brzmi: czy istnieje szybsza alternatywa cpdla kopiowania dużych plików w systemie Linux? (Czy są też jakieś flagi, cpktóre mogłyby użyć, które przyspieszyłyby kopiowanie?) Nawet gdybym mógł jakoś skrócić minutę kopiowania, to ogromnie by to pomogło.

Jestem pewien, że kupuję nowe, szybsze dyski sprzętowe, ale nie mam dostępu do takich zasobów. Nie jestem także administratorem systemu - jestem tylko (początkującym) użytkownikiem - więc nie mam dostępu do bardziej szczegółowych informacji na temat obciążenia na dyskach. Wiem, że chociaż kilkanaście osób korzysta z serwera plików codziennie, jestem jedyną osobą używającą tego konkretnego węzła / dysku lokalnego.


29
To daje około 29 MB / s, co jest dość szybkie, jeśli mnie zapytasz. Nie sądzę, aby było jakieś polecenie, które to przyspieszy, najprawdopodobniej „wąskie gardło” to: a) sieć lub b) serwer plików.
zadzwonić

5
tink jest w 100% poprawny. Nigdy nie widziałem niczego, co mogłoby to poprawić. Jedyne, co robiłem w przeszłości, to kompresowanie danych przed ich wysłaniem, ale to oznacza, że ​​dodajesz czas dzięki krokom kompresji i dekompresji, ale czasami warto, jeśli dane są dobrym kandydatem do bycia sprężony!
slm

3
Można również spróbować ddi rsyncporównać, który z nich działa szybciej w środowisku
Raza

@Salton Thanks. Jeszcze nie próbowałem dd, ale próbowałem rsync. Według czasu rzeczywistego czas wyniósł około 11,5 minuty, a czas systemowy - około 1,5 minuty time.
Andrew

2
Dziwię się, że nikt nie zauważył, że kopiowanie dysku lokalnego na dysk lokalny można zwiększyć, instalując wiele dysków. Kopiowanie z /dev/sda1do /dev/sdb1będzie szybsze niż kopiowanie z jednej lokalizacji /dev/sda1do innej lokalizacji na /dev/sda1lub innej partycji na, /dev/sdaponieważ dysk twardy nie będzie musiał wykonywać dodatkowych operacji wyszukiwania i odczytu (zakładając, że tradycyjne dyski twarde mają obracające się dyski i ruchome głowy; SSD jest oczywiście inny).
tripleee

Odpowiedzi:


53

% Procesora powinien być niski podczas kopiowania. Procesor informuje kontroler dysku, że „pobiera dane z sektorów X – Y do bufora pamięci w punkcie Z”. Potem idzie i robi coś innego (lub śpi, jeśli nie ma nic więcej). Sprzęt wyzwala przerwanie, gdy dane są w pamięci. Następnie procesor musi go skopiować kilka razy i mówi karcie sieciowej „transmituje pakiety w miejscach pamięci A, B i C”. Potem wraca do robienia czegoś innego.

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

  1. Jest to wspólne dla wszystkich korzystających z serwera plików (i ewentualnie połączenia między przełącznikami itp.)
  2. Jest to ograniczone szybkością, z jaką serwer plików może sobie poradzić z zapisem, pamiętając, że przepustowość dysku we / wy jest współdzielona przez wszystkich korzystających z niego.
  3. Nie określono sposobu uzyskiwania dostępu do serwera plików (NFS, CIFS (Samba), AFS itp.). Może być konieczne dostrojenie podłączenia do sieci, ale w jakimkolwiek ostatnim czasie wartości domyślne są zwykle całkiem rozsądne.

iostat -kx 10Przydaje się przydatne śledzenie wąskiego gardła . Pokaże wykorzystanie na lokalnych dyskach twardych. Jeśli możesz uruchomić to na serwerze plików, powie ci, jak zajęty jest ten serwer plików.

Ogólnym rozwiązaniem będzie przyspieszenie tego wąskiego gardła, na co oczywiście nie masz budżetu. Istnieje jednak kilka specjalnych przypadków, w których można znaleźć szybsze podejście:

  • Jeśli pliki są kompresowalne i masz szybki procesor, wykonanie minimalnej kompresji w locie może być szybsze. Coś jak, lzopa może gzip --fastest.
  • Jeśli zmieniasz tylko kilka bitów tu i tam, a następnie odsyłasz plik z powrotem, wysyłanie delty będzie znacznie szybsze. Niestety rsynctak naprawdę nie pomoże, ponieważ będzie musiał odczytać 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 możliwe jest, że możesz coś sfałszować, np. Maperem urządzeń (zobacz nowy cel z epoki DM) lub btrfs.
  • Jeśli kopiujesz te same dane na wiele komputerów, możesz użyć czegoś takiego jak udpcast, aby wysłać je na wszystkie komputery jednocześnie.

A ponieważ zauważyłeś, że nie jesteś administratorem systemu, zgaduję, że to znaczy, że masz administratora. Lub przynajmniej osoba odpowiedzialna za serwer plików i sieć. Prawdopodobnie powinieneś go zapytać, oni powinni być bardziej zaznajomieni ze specyfiką twojej konfiguracji. Twój administrator powinien przynajmniej być w stanie powiedzieć ci, jakiej szybkości transferu możesz się spodziewać.


+1 dla iostata -kx 10 :-)
n611x007

16

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


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

10

Twoja definicja efektywności jest odwrócona. Wydajniejsza implementacja marnuje mniej czasu procesora. Na kopii lokalnej osiągasz średnio około 74 MB / s przepustowości (odczyt + zapis), co jest tak dobre, jak pojedynczy dysk twardy.


1
Ups Kiedy powiedziałem „wydajny”, miałem na myśli „szybki”.
Andrew

10

Jeśli masz bezpośredni dostęp do SSH (lub SFTP) (zapytaj swojego administratora systemu), możesz użyć funkcji scpkompresji ( -C):

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

Oczywiście przydaje się to tylko wtedy, gdy plik jest kompresowalny, a to zużywa więcej czasu procesora, ponieważ będzie korzystał z szyfrowania (ponieważ jest nad SSH) i kompresji.


W takim przypadku przydatne byłoby wyłączenie szyfrowania. Pamiętaj, że staramy się zrobić kopię szybciej .
lgeorget

3
@lgeorget Podejrzewam, że narzut szyfrowania nie będzie znaczący, biorąc pod uwagę, jak powolne są dyski twarde. Zastanawiałem się nad dodaniem czegoś -c none, ale wydaje się to niestandardowe .
Przywróć Monikę

1
Mamy do czynienia z plikami ~ 20G, więc użycie szyfrowania jest dość nieefektywne, jeśli nie jest potrzebne.
lgeorget

1
@lgeorget Szyfrowanie może być wykonane o wiele szybciej niż przepustowość, którą dostaje, więc nic nie spowolni. Ale przejście przez SSH nie wydaje się konieczne. Jeśli potrzebujesz kompresji, na pewno są inne narzędzia?
Thomas

@Thomas Zaletą SSH jest to, że jeśli powinieneś mieć dostęp do zdalnego serwera, to prawie na pewno działa SSH. Inną opcją byłoby lokalne skompresowanie pliku, skopiowanie go na serwer, a następnie ssh
Przywróć Monikę

8

cpRealizacja jest najprawdopodobniej nie jest wąskim gardłem. Spróbuj obserwować użycie IO iotopzarówno na serwerze, jak i węźle klastra. To da ci pomysł, w jaki sposób 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 skopiujesz pliki w trybie peer-to-peer, a nie z jednego serwera do wszystkich klientów. Jest nieco bardziej skomplikowany do wdrożenia, ale możesz nawet spróbować użyć p2p z linii poleceń, takich jak hub 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ż podzielenie go na wspólne i określone części, a następnie rozprowadź wspólną część w sposób p2p.


1
Jeśli jesteś w sieci LAN, powinieneś być w stanie wykonać multicast zamiast peer-to-peer. Co powinno być szybsze i mniej obciążać sieć.
derobert

8

Charakter / 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, prawda?

Jeśli te pliki są kompresowalne lub zawierają podobne / identyczne części, masz dwa podejścia:

  • skompresuj je przed skopiowaniem lub utwórz tunel między komputerami z włączoną funkcją zip. Jeśli więc sieć stanowi wąskie gardło, będzie to nieco szybsze

  • jeśli pliki są bardzo podobne lub dzielą między nimi niektóre wspólne treści, spróbuj użyć rsync . Spędzi trochę czasu na znalezieniu tego, co wspólne dla plików, i nie będzie musiał kopiować go dosłownie , ponieważ odtworzy to na podstawie tego, co wspólne.

edytować

Czy będziesz musiał skopiować te pliki wiele razy? (jak kopia -> użyj tych plików -> zmień coś w plikach na komputerze A -> ponownie skopiuj pliki 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 pozostaje niezmienione.

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


6

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

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

Jeśli kopiujesz lokalnie, sprawdź, jak przebiega proces, jest POJEDYNCZY wątek, dlatego standardowe narzędzia linuksowe używają:

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

Nie ma ŻADNEJ współbieżności z tą operacją.

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

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

Aby uzyskać więcej informacji, zobacz stronę podręcznika dla bufora (1).

Komenda bufora konfiguruje dwa procesy do jednoczesnego uruchomienia procesu kopiowania: jeden do odczytu, a drugi do zapisu, i wykorzystuje bufor pamięci współużytkowanej do komunikacji danych między dwoma procesami. Bufor pamięci współdzielonej jest klasycznym okrągłym buforem, który zapobiega nadpisywaniu niepisanych danych i zapisywaniu danych już zapisanych. Użyłem tego programu, aby odciąć około 10-20% czasu kopiowania w transferach z dysku na taśmę.


W rzeczywistości istnieje współbieżność w „czytaniu bloku / pisaniu bloku”, ponieważ „pisanie bloku” tak naprawdę po prostu umieszcza go w buforze jądra, a jądro obsługuje faktyczny zapis bloku w tle (przynajmniej dopóki nie skończy się wyczerpanie pamięci RAM). Lub jeśli z jakiegoś powodu używasz O_DSYNC / O_SYNC.
derobert


1

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

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

rsync używa formy algorytmu kroczącego sumowania kontrolnego do wykrywania delt bez uprzedniej wiedzy o tym, co jest po drugiej stronie. Chociaż rsync wymaga więcej pracy, aby obliczyć delty, nie musi przechowywać całej historii plików.


1

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


3
Dobra ogólna obserwacja, ale ponieważ pytanie brzmi „~ 200 dużych plików - każdy ~ 20 GB”, nie sądzę, że można to uznać za rzeczywistą odpowiedź na ten problem.
manatwork

@manatwork ah .. nie czytałem wyraźnie. Myślałem, że ma 200 plików o łącznej wielkości 20 GB
Munim

0

Spróbuj bbcp . Testy w naszym środowisku ujawniły, że cp miał jakiś wbudowany regulator. Bądź ostrożny, ponieważ kiedy zdejmiesz gubernatora, możesz przekreślić serwer i spowodować awarię. W naszym przypadku przenieśliśmy serwer do trybu offline, aby wykonać kopię, więc szybciej było lepiej. To poprawiło czas transferu o kilka godzin.


0

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

Czasami jest zaskakujące, ile czasu spędza nawet kopiowanie na tym samym hoście (bez udziału sieci).

Zobacz moją odpowiedź na inne pytanie CP tutaj . Krótko mówiąc, nadpisywanie istniejącego pliku jest znacznie wolniejsze niż obcięcie go lub odłączenie najpierw, a następnie skopiowanie. Ten ostatni jest 8 razy szybszy dla pliku 1,2 GB.

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.