Jaki jest najszybszy sposób przesyłania ogromnych ilości danych między dwoma komputerami? [Zamknięte]

111

Często zdarza mi się taka sytuacja:

  • Mam serwer źródłowy z dyskiem twardym o pojemności 320 GB i 16 GB pamięci RAM ( dokładne specyfikacje są dostępne tutaj , ale ponieważ jest to problem, na który często wpadam również na innych komputerach, wolałbym, aby odpowiedź działała na każdym „rozsądna” maszyna z systemem Linux)
  • Mam serwer zapasowy z kilkoma terabajtami miejsca na dysku twardym ( dokładne specyfikacje tutaj , patrz wyłączenie odpowiedzialności powyżej)

Chcę przenieść 320 GB danych z serwera źródłowego na serwer docelowy (w szczególności dane z /dev/sda).

  1. Dwa komputery są fizycznie obok siebie, więc mogę poprowadzić kable między nimi.
  2. Jestem w sieci LAN i korzystam z nowego routera , co oznacza, że ​​prędkość mojej sieci powinna „idealnie” wynosić 1000 Mb, prawda?
  3. Bezpieczeństwo nie stanowi problemu. Jestem w sieci lokalnej i ufam wszystkim komputerom w sieci, w tym routerowi.
  4. (opcjonalnie) Niekoniecznie potrzebuję podpisanej sumy kontrolnej danych, ale podstawowe sprawdzanie błędów (takie jak upuszczone pakiety lub dysk staje się nieczytelny) powinno raczej zostać wykryte niż po prostu zniknąć w danych wyjściowych.

Szukałem tego pytania w Internecie i przetestowałem kilka poleceń. Ten, który pojawia się najczęściej, to:

ssh user@192.168.1.100 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz

Ta komenda okazała się zbyt wolna (działała przez godzinę, dane dostały tylko około 80 GB). Pakiet testowy 1 GB zajął około 1 minuty i 22 sekund, a po skompresowaniu był dwukrotnie szybszy. Wyniki mogły być również zniekształcone przez fakt, że przesłany plik jest mniejszy niż ilość pamięci RAM w systemie źródłowym.

Co więcej (i to zostało przetestowane na testowanych egzemplarzach 1 GB), mam problemy, jeśli użyję gzippolecenia i dd; plik wynikowy ma inną sumę kontrolną po wyodrębnieniu w celu, niż bezpośrednio w potoku. Wciąż próbuję dowiedzieć się, dlaczego tak się dzieje.

networking  backup  dd  file-transfer 
— IQAndreas
źródło
54
Nie zapomnij sneakernet
— gwillie
4
Czy chcesz przesłać /dev/sdajako obraz czy tylko pliki? Dlaczego rsync nie ma opcji? Jest /dev/sdamontowany podczas gdy ty dd?
— Jodka Lemon
15
Twoje dane dotyczące wydajności (1 GB / 80 sek., 80 GB / 1 godz.) Idealnie pasują do tego, czego powinniśmy oczekiwać na 100 MBit. Sprawdź swój sprzęt. ... i gerrit ma rację, 320 GB może być duże, ale „ogromna ilość danych” budzi złe oczekiwania.
— blafasel,
8
„Nigdy nie lekceważ przepustowości pociągu towarowego pełnego dysków”. .. Czy pytasz o przepustowość, opóźnienie lub mieszankę tych dwóch?
— keshlam
8
Mój przyjaciel zawsze mówił: „Nigdy nie lekceważ przepustowości stosu dysków twardych na ciężarówce”.
— AMADANON Inc.,

Odpowiedzi:

139

Ponieważ serwery są fizycznie obok siebie, a wspomniałeś w komentarzach, że masz do nich fizyczny dostęp, najszybszym sposobem byłoby wyjęcie dysku twardego z pierwszego komputera, umieszczenie go na drugim i przesłanie plików przez połączenie SATA.

— BlueRaja - Danny Pflughoeft
źródło
15
+1: Transfer fizyczny wydaje się najszybszą trasą, nawet jeśli oznacza to skądś uzyskanie dużego zewnętrznego dysku twardego. To około 40 funtów i prawdopodobnie spędziłeś już tyle czasu
— deworde
3
Całkowicie nie zgadzam się z tym pomysłem, jeśli ktoś osiąga pełną prędkość w sieci gigabitowej. Testowanie za pomocą NFS / SMB za pomocą przełącznika Gigabit Zyxel między mikrosterem HP Gen 7, a maszyną Pentium G630 daje transfer około 100 MB / s. (Dopóki nie opuszczę zewnętrznej krawędzi talerzy napędowych.) Myślę więc, że byłoby to realistycznie wykonane w niecałe 3 godziny. Chyba, że ​​używasz dysków SSD lub dysków / pamięci o bardzo wysokiej wydajności, nie sądzę, aby 2 kopie mogły wygenerować przepustowość 100 MB / s, co wymagałoby, aby każda operacja kopiowania wynosiła 200 MB / s, aby osiągnąć rentowność.
— Phizes
3
@Phizes: oczywiście nie kopiujesz do tymczasowego. To był zły pomysł deworda, a nie to, o czym wszyscy mówią. Punktem podłączenia napędu źródłowego do komputera docelowego jest przejście SATA-> SATA za pomocą dd(lub kopii drzewa systemu plików).
— Peter Cordes,
10
„Nigdy nie lekceważ przepustowości ciężarówki pełnej dysków twardych. Jedno wielkie opóźnienie”
— Kevin
3
@Kevin: tak, miałem na myśli, że bezpośrednia kopia między dyskami na tym samym komputerze jest co najmniej tak szybka, jak każda inna możliwa metoda. Podniosłem rzeczywiste liczby przepustowości, aby potwierdzić punkt Phize'a, że ​​przejście przez gigE jest dobre dla starego napędu OP, ale wąskie gardło dla nowych dysków. (Jednym z przypadków, w którym oba dyski w jednym komputerze nie są najlepszą opcją, jest to, że oddzielne komputery używające pamięci RAM do buforowania metadanych źródła i przeznaczenia są ważne, np. Dla synchronizacji miliardów plików.)
— Peter Cordes
69

netcat świetnie sprawdza się w sytuacjach takich jak ten, w których bezpieczeństwo nie stanowi problemu:

# on destination machine, create listener on port 9999
nc -l 9999 > /path/to/outfile

# on source machine, send to destination:9999
nc destination_host_or_ip 9999 < /dev/sda
# or dd if=/dev/sda | nc destination_host_or_ip 9999

Uwaga: jeśli używasz ddz GNU coreutils, możesz wysłać SIGUSR1do procesu, który wyśle ​​postęp do stderr. W przypadku BSD ddużyj SIGINFO.

pv jest jeszcze bardziej pomocny w zgłaszaniu postępów podczas kopiowania:

# on destination
nc -l 9999 | pv > /path/to/outfile

# on source
pv /dev/sda | nc destination_host_or_ip 9999
# or dd if=/dev/sda | pv | nc destination_host_or_ip 9999
— zackse
źródło
2
W przypadku drugiego przykładu jest to ddnawet wymagane, czy może pv/ samo dobrze ncleczyć /dev/sda? (Zauważyłem, że niektóre polecenia „wyrzucają” podczas próby odczytu specjalnych plików takich jak ten lub plików z 0x00bajtami)
— IQAndreas
5
@ user1794469 Czy kompresja pomoże? Myślę, że sieć nie jest tam, gdzie jest wąskie gardło.
— IQAndreas,
17
Nie zapominaj, że w bashjednym można używać > /dev/tcp/ IP  / portów i < /dev/tcp/ IP  / portu przekierowania zamiast rur do iz netcata odpowiednio.
— Incnis Mrsi,
5
Dobra odpowiedź. Gigabit Ethernet jest często szybszy niż prędkość dysku twardego, więc kompresja jest bezużyteczna. Aby przenieść kilka plików, rozważ tar cv sourcedir | pv | nc dest_host_or_ip 9999i cd destdir ; nc -l 9999 | pv | tar xv. Możliwych jest wiele odmian, możesz np. Chcieć zachować .tar.gzstronę docelową zamiast kopii. Jeśli skopiujesz katalog do katalogu, dla dodatkowego bezpieczeństwa możesz później wykonać rsync, np. Z dest rsync --inplace -avP user@192.168.1.100:/path/to/source/. /path/to/destination/.gwarantuje, że wszystkie pliki są rzeczywiście dokładnymi kopiami.
— Stéphane Gourichon
3
Zamiast korzystać z IPv4, możesz uzyskać lepszą przepustowość, używając IPv6, ponieważ ma on większą ładowność. Nawet go nie konfigurujesz, jeśli komputery obsługują IPv6, prawdopodobnie mają już adres lokalny dla łącza IPv6
— David Costa
33

  1. Czy korzystać z szybkiej kompresji.

    • Bez względu na to, jaki nośnik przesyłania danych - szczególnie w sieci lub usb - będziesz pracować z seriami danych do odczytu, pamięci podręcznej i zapisów, które nie będą dokładnie zsynchronizowane.
    • Oprócz oprogramowania układowego dysku, pamięci podręcznych dysków i pamięci podręcznych jądra / pamięci RAM, jeśli możesz również w jakiś sposób wykorzystać procesory systemu do skoncentrowania ilości danych wymienianych na serię , powinieneś to zrobić .
    • Każdy algorytm kompresji w ogóle automatycznie obsłuży rzadkie przebiegi danych wejściowych tak szybko, jak to możliwe, ale jest bardzo niewiele, które zajmą się resztą przy przepustowości sieci.
    • lz4 jest twoją najlepszą opcją tutaj:

      LZ4 jest bardzo szybkim bezstratnym algorytmem kompresji, zapewniającym szybkość kompresji przy 400 MB / s na rdzeń, skalowalnym z wielordzeniowym procesorem. Posiada również niezwykle szybki dekoder o prędkości wielu GB / s na rdzeń, zwykle osiągając ograniczenia prędkości pamięci RAM w systemach wielordzeniowych.

  2. Najlepiej nie szukaj niepotrzebnie.

    • To może być trudne do zmierzenia.

    • Jeśli na urządzeniu, z którego kopiujesz, jest dużo wolnego miejsca, a urządzenie nie zostało ostatnio wyzerowane, ale wszystkie źródłowe systemy plików powinny zostać skopiowane, prawdopodobnie warto poświęcić trochę czasu coś jak:

      </dev/zero tee >empty empty1 empty2; sync; rm empty*

    • Ale to zależy od tego, na jakim poziomie powinieneś czytać źródło. Zazwyczaj pożądane jest odczytywanie urządzenia od początku do końca z jego /dev/some_diskpliku urządzenia, ponieważ czytanie na poziomie systemu plików będzie zazwyczaj wymagało niesekwencyjnego przeszukiwania dysku do przodu i do tyłu i wokół dysku. Dlatego polecenie odczytu powinno wyglądać mniej więcej tak:

      </dev/source_device lz4 | ...

    • Jeśli jednak źródłowy system plików nie powinien zostać przesłany w całości, to czytanie na poziomie systemu plików jest dość nieuniknione, dlatego należy zebrać zawartość wejściową w strumieniu. paxjest ogólnie najlepszym i najprostszym rozwiązaniem w takim przypadku, ale możesz również rozważyć mksquashfs.

      pax -r /source/tree[12] | lz4 | ...
mksquashfs /source/tree[12] /dev/fd/1 -comp lz4 | ...

  3. Czy nie szyfrować z ssh.

    • Dodanie narzutu związanego z szyfrowaniem do zaufanego nośnika jest niepotrzebne i może poważnie zaszkodzić szybkości trwałych transferów, ponieważ odczyt danych wymaga dwukrotnego odczytu .
    • PRNG potrzebuje odczytane dane, a przynajmniej niektóre z nich, aby utrzymać losowości.
    • I oczywiście musisz również przesłać dane.
    • Musisz także sam przesłać narzut szyfrowania - co oznacza więcej pracy przy mniejszej ilości danych przesyłanych na serię .

    • Dlatego raczej powinieneś użyć netcat( lub, jak wolę, nmapbardziej zdolny projektncat ) do prostej kopii sieciowej, jak sugerowano gdzie indziej:

      ###  on tgt machine...
nc -l 9999 > out.lz4
###  then on src machine...
... lz4 | nc tgt.local 9999
— mikeserv
źródło
1
Fantastyczna odpowiedź. Jeden drobny punkt gramatyczny - „zmniejsza ilość danych, które muszą być wymieniane na serię” - Myślę, że używasz kompresji, aby zwiększyć gęstość informacji, ponieważ „serie” mają stałą szerokość, a zatem ilość wymienianych danych pozostaje stała chociaż informacje przesyłane dla serii mogą się różnić.
— Engineer Dollery,
@EngineerDollery - tak, to było głupie. Myślę, że tak jest lepiej
— mikeserv
@IQAndreas - poważnie rozważę tę odpowiedź. Osobiście używam Pigza, a wzrost prędkości jest niesamowity . Równoległość to ogromna wygrana; Procesory są znacznie szybsze niż jakakolwiek inna część potoku danych, więc wątpię, aby kompresja równoległa spowolniła cię (gzip nie jest równoległy). Możesz znaleźć to na tyle szybko, że nie ma motywacji do żonglowania dyskami twardymi; Nie zdziwiłbym się, gdyby ten był ogólnie szybszy (w tym czas wymiany dysku). Możesz testować z kompresją i bez. W każdym razie odpowiedź Diskswap firmy BlueRaja lub ta powinna być zaakceptowaną odpowiedzią.
— Mike S
Szybka kompresja to doskonała rada. Należy jednak zauważyć, że pomaga to tylko wtedy, gdy dane są w miarę kompresowalne, co oznacza, na przykład, że nie mogą one być już w formacie skompresowanym.
— Walter Tross,
@WalterTross - pomoże, jeśli jakiekolwiek dane wejściowe są kompresowalne, bez względu na stosunek, o ile zadanie kompresji przewyższa zadanie przesyłania. W nowoczesnym czterordzeniowym systemie lz4zadanie powinno z łatwością przyspieszyć nawet szeroko otwarte GIGe, a USB 2.0 nie ma szans. Poza tym lz4został zaprojektowany tak, aby działał tylko wtedy, gdy powinien - jest częściowo tak szybki, ponieważ wie, kiedy należy próbować kompresji, a kiedy nie. A jeśli jest to przesyłany plik urządzenia, to nawet wstępnie skompresowane dane wejściowe mogą się nieco skompresować, jeśli w źródłowym systemie plików występuje fragmentacja.
— mikeserv
25

Istnieje kilka ograniczeń, które mogą ograniczać prędkość przesyłania.

  1. Na potoku 1 Gb / s występuje nieodłączny narzut sieci. Zwykle zmniejsza to RZECZYWISTĄ przepustowość do 900 Mb / s lub mniej. Następnie należy pamiętać, że jest to ruch dwukierunkowy i należy oczekiwać znacznie mniej niż 900 Mb / s.

  2. Mimo że używasz „nowego routera”, czy jesteś pewien, że router obsługuje 1 Gb / s? Nie wszystkie nowe routery obsługują 1 Gb / s. Ponadto, chyba że jest to router klasy korporacyjnej, prawdopodobnie stracisz dodatkową przepustowość transmisji, ponieważ router będzie nieefektywny. Chociaż na podstawie tego, co znalazłem poniżej, wygląda na to, że osiągasz prędkość powyżej 100 Mb / s.

  3. Może wystąpić przeciążenie sieci z innych urządzeń współdzielących twoją sieć. Czy próbowałeś użyć bezpośrednio podłączonego kabla, tak jak powiedziałeś, że jesteś w stanie to zrobić?

  4. Jakiej ilości IO dysku używasz? Prawdopodobnie jesteś ograniczony nie przez sieć, ale przez dysk. Większość dysków twardych o prędkości 7200 obr./min osiąga jedynie około 40 MB / s. Czy w ogóle używasz raidu? Czy używasz dysków SSD? Czego używasz na drugim końcu?

Sugeruję użycie rsync, jeśli oczekuje się, że zostanie on ponownie uruchomiony dla kopii zapasowych. Możesz także scp, ftp (s) lub http za pomocą downloadera takiego jak filezilla na drugim końcu, ponieważ zrównoleglą one połączenia ssh / http / https / ftp. Może to zwiększyć przepustowość, ponieważ inne rozwiązania działają na jednej rurze. Pojedyncza rura / wątek jest nadal ograniczony faktem, że jest jednowątkowy, co oznacza, że ​​może być nawet związany z procesorem.

Dzięki rsync eliminujesz dużą złożoność swojego rozwiązania, a także umożliwia kompresję, zachowanie uprawnień i pozwala na częściowe transfery. Istnieje kilka innych powodów, ale ogólnie jest to preferowana metoda tworzenia kopii zapasowych (lub uruchamiania systemów tworzenia kopii zapasowych) w dużych przedsiębiorstwach. Commvault faktycznie używa rsync pod swoim oprogramowaniem jako mechanizmu dostarczania kopii zapasowych.

Na podstawie podanego przykładu 80 GB / h uzyskujesz około 177 Mb / s (22,2 MB / s). Wydaje mi się, że można łatwo podwoić to za pomocą rsync na dedykowanej linii Ethernet między dwoma urządzeniami, ponieważ udało mi się uzyskać to w moich własnych testach za pomocą rsync przez gigabit.

— Khrystoph
źródło
12
+1 dla rsync. Może nie być szybszy przy pierwszym uruchomieniu, ale na pewno będzie tak przez wszystkie kolejne czasy.
— Skrrp
4
> Większość dysków twardych o prędkości 7200 obr./min osiąga jedynie około 40 MB / s. IME jest bardziej prawdopodobne, że zobaczysz sekwencję ponad 100 MB / s na nowoczesnym dysku (w tym dyski ~ 5k). Chociaż może to być starszy dysk.
— Bob
2
@Bob: Ci nowocześni nadal potrafią odczytać tylko 5400 okrągłych utworów na minutę. Dyski te są nadal szybkie, ponieważ każda ścieżka zawiera więcej niż megabajt. Oznacza to, że są to również dość duże dyski. Mały dysk 320 GB nie może pomieścić zbyt wielu kilobajtów na ścieżkę, co z konieczności ogranicza ich prędkość.
— MSalters,
1
40 MB / s jest zdecydowanie bardzo pesymistyczne dla sekwencyjnego odczytu dla dowolnego napędu wyprodukowanego w ostatniej dekadzie. Obecne dyski 7200 RPM mogą przekraczać 100 MB / s, jak mówi Bob.
— hobbs
3
Gigabit Ethernet to pełny dupleks 1000 Mb / s . Otrzymujesz 1000 Mb / s (lub, jak mówisz, około 900 Mb / s w rzeczywistości) w każdym kierunku . Po drugie ... dyski twarde rutynowo otrzymują teraz 100 MB / s. 40 MB / s jest wolny, chyba że jest to dziesięcioletni dysk.
— derobert
16

Zajmujemy się tym regularnie.

Dwie główne metody, których używamy to:

  1. SATA / eSATA / sneakernet
  2. Bezpośrednie podłączenie NFS, następnie lokalne cplubrsync

Pierwszy zależy od tego, czy dysk można fizycznie przenieść. Nie zawsze tak jest.

Drugi działa zaskakująco dobrze. Zasadniczo maksymalizujemy połączenie 1 Gb / s raczej łatwo dzięki bezpośrednim mocowaniom NFS. Nigdzie nie zbliżysz się do tego przy pomocy scp, dd over ssh lub czegoś podobnego (często uzyskasz maksymalną stawkę podejrzanie zbliżoną do 100mpbs). Nawet na bardzo szybkich procesorach wielordzeniowych natrafisz na wąskie gardło związane z maksymalną przepustowością kryptograficzną jednego z rdzeni na najwolniejszym z dwóch komputerów, co jest przygnębiająco powolne w porównaniu z pełnoprzepustowymi procesorami lub rsync na nieszyfrowanym montażu sieciowym. Od czasu do czasu będziesz uderzył w ścianę IOPS na chwilę i być zatrzymany na około ~ 53MB / s zamiast bardziej typowego ~ 110MB / s, ale to jest zwykle krótkotrwałe, chyba że źródło lub cel jest rzeczywiściepojedynczy dysk, możesz zostać ograniczony przez stałą szybkość samego dysku (który zmienia się wystarczająco z przypadkowych powodów, których nie poznasz, dopóki go nie wypróbujesz) - meh.

Ustawienie NFS może być trochę denerwujące, jeśli działa na nieznanej dystrybucji, ale ogólnie rzecz biorąc, był to najszybszy sposób na jak najlepsze wypełnienie rur. Ostatnim razem, gdy robiłem to z prędkością ponad 10 Gb / s, nigdy nie dowiedziałem się, czy to maksymalnie zwiększyło połączenie, ponieważ transfer został zakończony, zanim wróciłem po kawę - więc może istnieć jakiś naturalny limit, który tam osiągnąłeś. Jeśli masz kilka urządzeń sieciowych między źródłem a miejscem docelowym, możesz napotkać pewne niewielkie opóźnienia lub czkawkę z efektem slinky sieci, ale generalnie działa to w całym biurze (bez ingerencji w inny ruch) lub z jednego końca centrum danych do drugi (chyba że masz jakieś wewnętrzne filtrowanie / inspekcję, w którym to przypadku wszystkie zakłady są wyłączone ).

EDYTOWAĆ

Zauważyłem trochę gadania na temat kompresji ... nie kompresuj połączenia. Spowolni cię w taki sam sposób, jak warstwa krypto. Wąskim gardłem zawsze będzie pojedynczy rdzeń, jeśli skompresujesz połączenie (a nawet nie uzyskasz szczególnie dobrego wykorzystania magistrali tego rdzenia). Najwolniejszą rzeczą, jaką możesz zrobić w tej sytuacji, jest użycie zaszyfrowanego, skompresowanego kanału między dwoma komputerami siedzącymi obok siebie na połączeniu 1 Gb / s lub wyższym.

PRZYSZŁOŚĆ

Ta rada obowiązuje od połowy 2015 r. Prawie na pewno nie będzie tak przez wiele kolejnych lat. Więc weź wszystko z odrobiną soli, a jeśli regularnie mierzysz się z tym zadaniem, wypróbuj różne metody na rzeczywistych obciążeniach zamiast wyobrażać sobie, że uzyskasz coś zbliżonego do teoretycznych optymalnych wartości, a nawet zaobserwowane współczynniki kompresji / przepustowości kryptograficznej typowe dla takich rzeczy jak sieć ruch, z którego większość ma charakter tekstowy (protip: transfery zbiorcze zwykle składają się głównie z obrazów, audio, wideo, plików baz danych, kodu binarnego, formatów plików biurowych itp., które są już skompresowanena swój sposób i bardzo mało korzystają z przejścia przez kolejną procedurę kompresji, której rozmiar bloku kompresji prawie na pewno nie jest zgodny z już skompresowanymi danymi binarnymi ...).

Wyobrażam sobie, że w przyszłości koncepcje, takie jak SCTP, zostaną przeniesione w bardziej interesujące miejsce, w którym typowe są połączone połączenia (lub wewnętrznie połączone kanałowe połączenia światłowodowe), a każdy kanał może odbierać strumień niezależny od innych i każdy Strumień może być kompresowany / szyfrowany równolegle itp. itd. To byłoby wspaniałe! Ale dzisiaj tak nie jest w 2015 r. I chociaż fantazjowanie i teoretyzowanie jest miłe, większość z nas nie ma niestandardowych klastrów pamięci działających w komorze kriokomórkowej zasilających dane bezpośrednio do wnętrza Blue Gene / Q generujących odpowiedzi dla Watsona. To po prostu nie jest rzeczywistość. Nie mamy też czasu na wyczerpujące przeanalizowanie ładunku danych, aby dowiedzieć się, czy kompresja jest dobrym pomysłem, czy nie - sam transfer zostałby zakończony przed zakończeniem analizy,

Ale...

Czasy się zmieniają, a moje zalecenie przeciw kompresji i szyfrowaniu nie będzie ważne. Naprawdę chciałbym, aby ta rada została wkrótce obalona w typowej sprawie . Ułatwi to moje życie.

— zxq9
źródło
1
@ jofel Tylko wtedy, gdy prędkość sieci jest mniejsza niż przepustowość kompresji procesora - co nigdy nie jest prawdą w przypadku połączeń o przepustowości 1 gb / s lub wyższych. Jednak w typowym przypadku sieć stanowi wąskie gardło, a kompresja skutecznie przyspiesza - ale nie tak opisuje OP.
— zxq9
2
lz4jest wystarczająco szybki, aby nie powodować wąskiego gardła, ale w zależności od tego, co chcesz zrobić z kopią, możesz potrzebować go bez kompresji. lzop też jest dość szybki. W moim i5-2500k Sandybridge (3,8 GHz) lz4 < /dev/raid0 | pv -a > /dev/nullidzie z prędkością ~ 180 MB / s, ~ 105 MB / s, w sam raz na gigE. Dekompresja po stronie odbiorczej jest jeszcze łatwiejsza na CPU.
— Peter Cordes,
1
Ponadto 3,8 GHz jest nieco szybszy niż większość uruchomionych procesorów serwerowych (lub wiele systemów klasy biznesowej dowolnego smaku, przynajmniej tak się przyzwyczaiłem). Bardziej powszechne jest obserwowanie znacznie większej liczby rdzeni przy znacznie niższych prędkościach zegara w centrach danych. Równoległość obciążeń przesyłowych nie była problemem przez długi czas, więc w większości przypadków utknęliśmy z maksymalną prędkością jednego rdzenia - ale spodziewam się, że to się zmieni teraz, gdy prędkości zegara są generalnie maksymalne, ale prędkości sieci wciąż mają długa droga przed osiągnięciem maksimum.
— zxq9,
2
Całkowicie nie zgadzam się z twoimi komentarzami dotyczącymi kompresji. Zależy to całkowicie od ściśliwości danych. Gdyby można uzyskać współczynnik kompresji 99,9%, głupotą byłoby nie robić tego - po co przesyłać 100 GB, skoro można uniknąć transferu 100 MB? Nie sugeruję, że ten poziom kompresji ma miejsce w przypadku tego pytania, po prostu pokazując, że należy to rozpatrywać indywidualnie dla każdego przypadku i że nie ma bezwzględnych zasad.
— Engineer Dollery,
1
@EngineerDollery nie grać w transferze luzem w ogóle w świecie rzeczywistym. Robię to prawie codziennie i przetestowałem różne metody i ustawienia. W ogólnym przypadku duże masowe transfery nieznanych danych (wszystko, na co nie masz czasu na przeprowadzenie testów dostrajania kompresji - co oznacza w praktyce prawie wszystko w dowolnym centrum danych, infrastrukturze korporacyjnej, serwerze dla małych firm lub sieci domowej) to dużo szybciej przez połączenie 1 Gb / s lub wyższe. Idź spróbuj. Najlepszym sposobem na kompresję jest zazwyczaj tekst. Tekst zawiera niewielki ułamek typowego ładunku masowego transferu.
— zxq9,
6

Sprytne narzędzie, którego użyłem w przeszłości to bbcp. Jak widać tutaj: https://www.slac.stanford.edu/~abh/bbcp/ .

Zobacz także http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm

Dzięki temu narzędziu miałem bardzo duże prędkości transferu.

— Ciemne serce
źródło
1
Drugi link tej odpowiedzi wyjaśnia, jak dostroić parametry jądra, aby osiągnąć wyższe prędkości. Autor ma tam 800 megabajtów na sekundę w łączach 10G, a niektóre rzeczy wydają się mieć zastosowanie do łączy 1Gbps.
— Stéphane Gourichon
5

Jeśli jakoś dostaniesz pierwsze przejście (przez drut / sneakernet / cokolwiek), możesz skorzystać rsyncz niektórych opcji, które mogą znacznie przyspieszyć kolejne transfery. Bardzo dobrą drogą byłoby:

rsync -varzP sourceFiles destination

Dostępne opcje: pełny, tryb archiwizacji, rekurencyjny, kompresuj, Częściowy postęp

— Hopping Bunny
źródło
2
Rsync jest bardziej niezawodny niż netcat, ale archiwum implikuje rekurencję, więc r jest redundantne.
— Tanath,
Ponadto -zmoże być niewiarygodnie powolny w zależności od procesora i przetwarzanych danych. Podczas wyłączania kompresji doświadczyłem transferów z 30 MB / s do 125 MB / s.
— lip
4

Dodano naleganie na oryginalny plakat w komentarzach do odpowiedzi Zacksego, chociaż nie jestem pewien, czy jest on najszybszy w typowych okolicznościach.

bashma specjalną składnię przekierowanie:
dla wyjścia:      > /dev/tcp/ IP  / portu
dla wejścia:       < /dev/tcp/ IP  / portu
IP ban być IP kropką dziesiętną lub nazwa hosta; zakaz portu może być liczbą dziesiętną lub nazwą portu z /etc/services.

Brak rzeczywistego /dev/tcp/katalogu. Jest to specjalna syntaktyczna kludge, która nakazuje bashutworzenie gniazda TCP, połączenie go z określonym miejscem docelowym, a następnie wykonanie tej samej czynności, co zwykłe przekierowanie pliku (mianowicie zastąpienie odpowiedniego standardowego strumienia gniazdem za pomocą dup2 (2)).

Dlatego można przesyłać strumieniowo dane z ddlub tarna maszynę źródłową bezpośrednio przez TCP. Lub odwrotnie, aby przesyłać strumieniowo dane tarlub coś podobnego bezpośrednio przez TCP. W każdym razie jeden zbędny netcat jest eliminowany.

Uwagi na temat netcat

Istnieje niespójność w składni między klasycznym netcat a GNU netcat . Użyję klasycznej składni, do której jestem przyzwyczajony. Wymienić -lpz -lGNU netcata.

Nie jestem również pewien, czy GNU netcat akceptuje -qprzełączanie.

Przesyłanie obrazu dysku

(Wzdłuż linii odpowiedzi Zackse.)
W miejscu docelowym:

nc -lp 9999 >disk_image

U źródła:

dd if=/dev/sda >/dev/tcp/destination/9999
 

Tworzenie archiwum tar.gz za pomocą tar

Na miejscu:

nc -lp 9999 >backup.tgz

U źródła:

tar cz files or directories to be transferred >/dev/tcp/destination/9999

Wymień .tgzsię .tbzi czze cjuzyskać bzip2-compressed archiwum.

Przesyłanie z natychmiastowym rozszerzeniem do systemu plików

Również z tar.
Na miejscu:

cd backups
tar x </dev/tcp/destination/9999

U źródła:

tar c files or directories to be transferred |nc -q 1 -lp 9999

Będzie działał bez -q 1, ale netcat utknie po zakończeniu danych. Zobacz tar (1), aby uzyskać wyjaśnienie dotyczące składni i zastrzeżeń tar. Jeśli istnieje wiele plików o wysokiej redundancji (niskiej entropii), można wypróbować kompresję (np. czI xzzamiast ci x), ale jeśli pliki są typowe, a sieć jest wystarczająco szybka, to tylko spowolni proces. Zobacz odpowiedź mikeserv, aby uzyskać szczegółowe informacje na temat kompresji.

Alternatywny styl (docelowy port nasłuchuje)

Na miejscu:

cd backups
nc -lp 9999 |tar x

U źródła:

tar c files or directories to be transferred >/dev/tcp/destination/9999
— Incnis Mrsi
źródło
bash najwyraźniej nie może „nasłuchiwać” na gnieździe, aby poczekać i otrzymać plik: unix.stackexchange.com/questions/49936/…, więc musisz użyć czegoś innego przez co najmniej połowę połączenia ...
— rogerdpack
2

Chciałbym użyć tego skryptu, który napisałem i który potrzebuje socatpakietu.

Na maszynie źródłowej:

tarnet -d wherefilesaretosend pass=none 12345 .

Na maszynie docelowej:

tarnet -d wherefilesaretogo pass=none sourceip/12345

Jeśli vbufpakiet (Debian, Ubuntu) już tam jest, to nadawca pliku pokaże postęp danych. Odbiornik plików pokaże, jakie pliki są odbierane. Opcji pass = można użyć tam, gdzie dane mogą zostać ujawnione (wolniej).

Edytować:

Użyj -nopcji, aby wyłączyć kompresję, jeśli procesor jest szyjką butelki.

— Skaperen
źródło
2

Jeśli budżet nie jest głównym problemem, możesz spróbować podłączyć dyski za pomocą 12-rdzeniowego „złącza dysku” Intel Xeon E5. To złącze jest zwykle tak potężne, że możesz nawet uruchomić na nim obecne oprogramowanie serwera. Z obu serwerów!

To może wydawać się zabawną odpowiedzią, ale powinieneś naprawdę zastanowić się, dlaczego przenosisz dane między serwerami, a jeśli duży ze wspólną pamięcią i pamięcią masową może mieć większy sens.

Nie jesteś pewien aktualnych specyfikacji, ale powolny transfer może być ograniczony szybkością dysku, a nie siecią?

— użytkownik133111
źródło
1

Jeśli dbasz tylko o kopie zapasowe, a nie bajt o bajtową kopię dysku twardego, polecam backupPC. http://backuppc.sourceforge.net/faq/BackupPC.html Konfiguracja jest trochę trudna, ale przenosi się bardzo szybko.

Mój początkowy czas transferu około 500G danych wynosił około 3 godzin. Kolejne kopie zapasowe mają miejsce w około 20 sekund.

Jeśli nie jesteś zainteresowany kopiami zapasowymi, ale próbujesz zsynchronizować różne rzeczy, to rsync lub unison lepiej pasują do twoich potrzeb.

Bajt dla bajtowej kopii dysku twardego jest zwykle okropnym pomysłem do tworzenia kopii zapasowych (brak przyrostów, brak oszczędności miejsca, dysk nie może być używany, musisz wykonać kopię zapasową „pustej przestrzeni” i musisz wykonać kopię zapasową śmieci (np. plik wymiany 16 G lub 200 G zrzutów rdzenia lub kilka takich). Korzystając z rsync (lub backuppc lub innych), możesz tworzyć „migawki” w czasie, dzięki czemu możesz przejść do „tego, jak wyglądał twój system plików 30 minut temu” za pomocą bardzo małe obciążenie.

To powiedziawszy, jeśli naprawdę chcesz przesłać bajt do kopiowania bajtów, to twój problem będzie leżał w transferze, a nie w pobieraniu danych z dysku. Bez 400 GB pamięci RAM transfer plików 320G zajmuje bardzo dużo czasu. Korzystanie z protokołów, które nie są zaszyfrowane, jest opcją, ale bez względu na wszystko, musisz po prostu tam usiąść i poczekać kilka godzin (przez sieć).

— Coteyr
źródło
1
w jaki sposób 400G pamięci RAM przyspiesza transfer danych?
— Skaperen
Nie jestem pewien, czy taka była intencja, ale przeczytałem, że „jakikolwiek średni wolniejszy niż transfer pamięci RAM do RAM zajmie trochę czasu”, a nie „kup 400 GB pamięci RAM, a transfer HDD na HDD pójdzie szybciej”.
— MichaelS
Tak, baran zbuforuje dla ciebie i będzie wydawał się szybszy. Możesz wykonać transfer HD na HD z buforowaniem RAM do końca i będzie to wydawać się bardzo szybkie. Spłukanie na dysk zajmie również sporo sprytu, ale HD na RAM na RAM na HD na HD jest szybszy niż HD na HD. (Pamiętaj, że i tak musisz wykonać HD na RAM na RAM na HD na HD, ale jeśli masz mniej niż cały rozmiar transferu RAM, będziesz musiał „spłukać” w segmentach.)
— coteyr
Innym sposobem jest to, że aby skompresować lub po prostu wysłać cały dysk źródłowy, należy go wczytać do pamięci RAM. Jeśli nie pasuje od razu, musi odczytać segment, wysłać, odrzucić segment, wyszukać, odczytać segment itp. Jeśli wszystko pasuje od razu, musi po prostu odczytać wszystko naraz. To samo w miejscu docelowym.
— coteyr
1
HD na RAM na RAM na HD na HD jest szybszy niż HD na HD Jak może być szybszy?
— AL
1

Niezależnie od programu zwykle stwierdziłem, że „ściąganie” plików przez sieć jest szybsze niż „wypychanie”. Oznacza to, że zalogowanie się na komputerze docelowym i wykonanie odczytu jest szybsze niż zalogowanie się na komputerze źródłowym i wykonanie zapisu.

Ponadto, jeśli zamierzasz użyć dysku pośredniego, zastanów się: Weź dysk zewnętrzny (jako pakiet lub osobny dysk podłączony do stacji dokującej), który używa eSATA zamiast USB. Następnie na każdym z dwóch komputerów albo zainstaluj kartę z portem eSATA, albo uzyskaj prosty kabel adaptera, który doprowadza jeden z wewnętrznych portów SATA do zewnętrznego złącza eSATA. Następnie podłącz dysk do komputera źródłowego, włącz dysk i poczekaj, aż się automatycznie zamontuje (możesz zamontować ręcznie, ale jeśli robisz to wielokrotnie, równie dobrze możesz umieścić go w pliku fstab). Następnie skopiuj; będziesz pisać z taką samą prędkością jak na dysku wewnętrznym. Następnie odmontuj dysk, wyłącz zasilanie, podłącz do drugiego komputera, włącz zasilanie, poczekaj na automatyczne podłączenie i czytaj.

— Mike Ciaraldi
źródło
2
Czy możesz podać szczegóły, w jaki sposób „wyciągasz” pliki? Z jakich narzędzi korzystasz i czy możesz podać próbkę wykazującą ten efekt?
— STW,
Nie jestem pewien, czy będzie to bardziej kompletna odpowiedź, ale rozważmy następujący scenariusz: Załóżmy, że masz dwa komputery: foo i bar i chcesz skopiować dane z foo do bar. (1) Zaloguj się do foo, a następnie zdalnie zamontuj dysk, który jest fizycznie podłączony do paska. Następnie kopiujesz z dysku foo do zdalnie zamontowanego katalogu (który jest fizycznie na pasku). Nazwałem to wypychaniem danych na inny komputer. (2) Porównaj to z innym sposobem kopiowania tych samych danych. Zaloguj się do paska, zdalnie zamontuj katalog dołączony do foo i czytaj z foo na dysku bar. To ciągnie.
— Mike Ciaraldi,
To kopiowanie można wykonać za pomocą polecenia Linux cp, menedżera plików GUI lub dowolnego innego sposobu kopiowania plików. Wydaje mi się, że ciągnięcie okazuje się szybsze, ponieważ pisanie jest wolniejsze niż czytanie, a więcej decyzji dotyczących sposobu zapisywania na dysku docelowym podejmowanych jest na tym samym komputerze, do którego podłączony jest dysk, więc jest mniej narzutu. Ale może nie jest tak już w przypadku bardziej nowoczesnych systemów.
— Mike Ciaraldi,
1

Polecam przyjrzeć się zespołowi NIC. Wymaga to użycia wielu połączeń sieciowych działających równolegle. Zakładając, że naprawdę potrzebujesz więcej niż 1 Gb transferu, a 10 Gb jest kosztowne, 2 Gb zapewniane przez zespół NIC byłoby niewielkim kosztem, a twoje komputery mogą już mieć dodatkowe porty.

— Byron Jones
źródło
Jeśli masz na myśli LACP (Link Aggregation Control Protocol), to nie zobaczysz wzrostu prędkości. Zapewniał nadmiarowość i pewną możliwość obsługi większej liczby równoczesnych połączeń, ale nie zapewni przyspieszenia dla tego rodzaju transferu.
— STW
@STW: Wymaga obsługi przełączników w celu agregacji dwóch łączy do jednego komputera w łącze 2 Gb, ale jest to możliwe. Przydatne tylko wtedy, gdy oba komputery mają łącze 2 gb do przełącznika. Jeśli masz dwa kable z NIC <-> NIC, bez przełącznika, to też powinno działać, ale nie jest to bardzo przydatne (chyba że masz trzeci NIC w jednym komputerze, aby utrzymać połączenie z Internetem).
— Peter Cordes,
czy jest konkretna nazwa tej funkcji w przełącznikach?
— STW,
Istnieje kilka odmian łączenia NIC, EtherChannel itp. STW jest odpowiedni dla niektórych konfiguracji, to nie pomoże, ale dla niektórych konfiguracji byłoby. Wszystko sprowadza się do tego, czy połączony kanał przyspiesza działanie pojedynczego gniazda IP, czy nie. Musisz zbadać szczegóły, aby ustalić, czy jest to realne rozwiązanie dla Ciebie.
— Byron Jones,
802.3ad to otwarty standard, którego szukasz na swoich przełącznikach. Jednak w ramach szybkiego włamania możesz po prostu podłączyć do sieci dodatkowe karty sieciowe i nadać im odpowiednie adresy IP w oddzielnych podsieciach w prywatnej przestrzeni adresowej. (port hosta 1 i host hosta 2 otrzymują jedną podsieć, host 1 port b i host 2 port b uzyskują inną podsieć). Następnie uruchom dwa równoległe zadania, aby wykonać transfer. Będzie to o wiele prostsze niż poznanie tajników Etherchannel, 802.3ad itp.
— Dan Pritts,
1

FWIW, zawsze używałem tego:

tar -cpf - <source path> | ssh user@destserver "cd /; tar xf -"

Chodzi o to, że ta metoda zachowa uprawnienia do plików / folderów między komputerami (zakładając, że na obu istnieją ci sami użytkownicy / grupy) (Zwykle robię to, aby skopiować obrazy dysków wirtualnych, ponieważ mogę używać parametru -S do obsługi rzadkich plików. )

Właśnie przetestowałem to między dwoma zajętymi serwerami i zarządzałem ~ 14 GB w 216 s (około 64 MB / s) - może lepiej poradzić sobie między dedykowanymi maszynami i / lub kompresją ... YMMV

$ date; tar -cpf - Installers | ssh elvis "cd /home/elvis/tst; tar xf -"; date
Wed Sep  9 15:23:37 EDT 2015
Wed Sep  9 15:27:13 EDT 2015

$ du -s Installers
14211072   Installers
— ttstooge
źródło
1

O ile nie chcesz wykonywać analizy sądowej systemu plików, użyj programu zrzutu / przywracania dla swojego systemu plików, aby uniknąć kopiowania wolnego miejsca, którego FS nie używa. W zależności od posiadanego systemu plików zazwyczaj zachowuje to wszystkie metadane, w tym ctime. numery i-węzłów mogą się jednak zmieniać, zależnie od systemu plików (xfs, ext4, ufs ...).

Celem przywracania może być plik w systemie docelowym.

Jeśli chcesz mieć obraz całego dysku z tablicą partycji, możesz uzyskać ddpierwszy 1M dysku, aby uzyskać tablicę partycji / bootloadery / rzeczy, ale potem xfsdumppartycje.

Nie mogę stwierdzić na podstawie zrzutu informacji, jaki system plików faktycznie posiadasz. Jeśli jest to ufs BSD, to myślę, że ma program zrzutu / przywracania. Jeśli to ZFS, cóż, IDK, może być coś.

Generalnie dyski z pełnym kopiowaniem są zbyt wolne, by cokolwiek poza sytuacjami odzyskiwania. W ten sposób nie można również tworzyć przyrostowych kopii zapasowych.

— Peter Cordes
źródło
1

Możesz także skonfigurować systemy tak, aby miały wspólną pamięć!

Rozważam, że są one obok siebie i prawdopodobnie zrobisz to jeszcze raz i jeszcze raz ....

— użytkownik133526
źródło
1

Co powiesz na ethernetowy kabel skrzyżowany? Zamiast polegać na prędkościach bezprzewodowych, masz limit prędkości przewodowej karty sieciowej.

Oto podobne pytanie z kilkoma przykładami tego rodzaju rozwiązania.

Najwyraźniej wystarczy dziś typowy kabel Ethernet. Oczywiście im lepsza jest twoja karta sieciowa, tym szybszy jest transfer.

Podsumowując, jeśli konieczna jest jakakolwiek konfiguracja sieci, należy ograniczyć się do zwykłego ustawiania statycznych adresów IP serwera i komputera zapasowego za pomocą maski podsieci 255.255.255.0

Powodzenia!

Edytować:

@Khrystoph dotknął tego w swojej odpowiedzi

Jak to poprawi prędkości? Czy możesz wyjaśnić swoją odpowiedź?
— AL
1
Potencjalnie poprawiłoby to szybkość, ponieważ nie musiałbyś się martwić spowolnieniem sieci pośredniej. Jeśli chodzi o kable Ethernet „typowe” w porównaniu do „crossover” - w razie potrzeby sieć Ethernet 1 Gb automatycznie się skrzyżuje. Przełączniki ethernetowe HP zrobią to z prędkością 100 Mb. Inne marki, generalnie nie, i będziesz potrzebować zwrotnicy, jeśli utkniesz na 100Mb.
— Dan Pritts,
1

Kilku ludzi zaleca pominięcie ssh, ponieważ szyfrowanie cię spowolni. Nowoczesne procesory mogą być rzeczywiście wystarczająco szybkie przy 1 Gb, ale OpenSSH ma problemy z wewnętrzną implementacją okienkowania, która może drastycznie spowolnić.

Jeśli chcesz to zrobić za pomocą ssh, spójrz na HPN SSH . Rozwiązuje problemy z okienkowaniem i dodaje szyfrowanie wielowątkowe. Niestety musisz przebudować ssh zarówno na kliencie, jak i serwerze.

— Dan Pritts
źródło
0

OK Próbowałem odpowiedzieć na to pytanie dla dwóch komputerów z „bardzo dużymi rurami” (10 Gbe), które są „blisko” siebie.

Problem, na który się tu natkniesz, to: większość kompresji spowoduje wąskie gardło w procesorze, ponieważ rury są tak duże.

wydajność przesyłania pliku 10 GB (połączenie sieciowe 6 Gb [linode], dane nieskompresowane):

$  time bbcp 10G root@$dest_ip:/dev/null
0m16.5s 

iperf:

server: $ iperf3 -s -F /dev/null
client:
$ time iperf3 -c $dest_ip -F 10G -t 20 # -t needs to be greater than time to transfer complete file
0m13.44s
(30% cpu)

netcat (1.187 openbsd):

server: $ nc -l 1234 > /dev/null
client: $ time nc $dest_ip 1234 -q 0 < 10G 
0m13.311s
(58% cpu)

scp:

$ time /usr/local/bin/scp 10G root@$dest_ip:/dev/null
1m31.616s
scp with hpn ssh patch (scp -- hpn patch on client only, so not a good test possibly): 
1m32.707s

socat:

server:
$ socat -u TCP-LISTEN:9876,reuseaddr OPEN:/dev/null,creat,trunc
client:
$ time socat -u FILE:10G TCP:$dest_ip:9876
0m15.989s

I dwa pudełka na 10 Gbe, nieco starsze wersje netcat (CentOs 6.7), plik 10 GB:

nc: 0m18.706s (100% cpu, v1.84, no -q option
iperf3: 0m10.013s (100% cpu, but can go up to at least 20Gbe with 100% cpu so not sure it matters)
socat: 0m10.293s (88% cpu, possibly maxed out)

Tak więc w jednym przypadku netcat użył mniej procesora, w drugim socat, więc YMMV.

Z netcat, jeśli nie ma opcji „-N -q 0”, może przesyłać obcięte pliki, bądź ostrożny ... inne opcje, takie jak „-w 10”, mogą również powodować obcięte pliki.

W prawie wszystkich tych przypadkach procesor jest maksymalizowany, a nie sieć. scpmaksymalizuje przy około 230 MB / s, ustalając jeden rdzeń przy 100% wykorzystaniu.

Iperf3 niestety tworzy uszkodzone pliki. Niektóre wersje programu netcat wydają się nie przesyłać całego pliku, co jest bardzo dziwne. Szczególnie starsze wersje.

Różne inkantacje „gzip as a pipe to netcat” lub „mbuffer” również wydawały się maksymalnie obciążać procesor przy pomocy gzip lub mbuffer, więc nie skutkowały szybszym transferem przy tak dużych rurach. lz4 może pomóc. Ponadto niektóre z rzeczy, które próbowałem w gzipie, spowodowały uszkodzenie transferu bardzo dużych plików (> 4 GB), więc bądźcie ostrożni :)

Kolejną rzeczą, która może działać szczególnie przy wyższych opóźnieniach (?), Jest dostrajanie ustawień tcp. Oto przewodnik wymieniający sugerowane wartości:

http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm i https://fasterdata.es.net/host-tuning/linux/ (z innej odpowiedzi) ewentualnie ustawienia IRQ: https://fasterdata.es .net / host-tuning / 100g-tuning /

sugestie z linode, dodaj do /etc/sysctl.conf:

net.core.rmem_max = 268435456 
net.core.wmem_max = 268435456 
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_no_metrics_save = 1
net.core.default_qdisc = fq

Dodatkowo chcieliby, abyś uruchomił:

 /sbin/ifconfig eth0 txqueuelen 10000

warto dwukrotnie sprawdzić po poprawkach, aby upewnić się, że zmiany również nie powodują szkód.

Warto również dostroić rozmiar okna: https://iperf.fr/iperf-doc.php#tuningtcp

Jednak przy wolnych (er) połączeniach kompresja może zdecydowanie pomóc. Jeśli masz duże potoki, bardzo szybka kompresja może pomóc w łatwo kompresujących danych, nie próbowałem tego.

Standardową odpowiedzią na „synchronizowanie dysków twardych” jest synchronizacja plików, co pozwala uniknąć transferu tam, gdzie to możliwe.

Inna opcja: użyj „równoległego scp” (w taki czy inny sposób), wtedy użyje więcej rdzeni ...

— rogerdpack
źródło
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.