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

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.

% 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ć.

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.

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.

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.

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.

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.

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ę.

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

Twitter używa https://github.com/lg/murder

Istnieje również BTSync , którego możesz spró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ć 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.

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

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.

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.