Existuje rychlejší alternativa k cp pro kopírování velkých souborů (~ 20 GB)?

% CPU by mělo být během kopírování nízké. CPU řekne diskovému řadiči, že „chytí data ze sektorů X – Y do vyrovnávací paměti v Z“. Pak to jde a dělá něco jiného (nebo spí, pokud nic jiného není). Hardware spustí přerušení, když jsou data v paměti. Poté jej CPU musí několikrát zkopírovat a řekne síťové kartě „přenášet pakety na paměťových místech A, B a C“. Pak se vrací k tomu, že dělá něco jiného.

Vytlačujete ~ 240 Mbps.Na gigabitové LAN byste měli být schopni dělat alespoň 800 Mbps, ale:

1. To sdílí každý, kdo používá souborový server (a možná i spojení mezi přepínači atd.)
2. To je omezeno rychlostí, kterou dokáže souborový server zvládnout zápis, přičemž mějte na paměti, že jeho šířku pásma I / O disku sdílí každý, kdo jej používá.
3. Neuvedli jste, jak přistupujete k souborovému serveru (NFS, CIFS (Samba), AFS atd.). Možná budete muset vyladit připojení k síti, ale u všeho, co je nedávné, jsou výchozí hodnoty obvykle docela rozumné.

Chcete-li vyhledat úzké místo, iostat -kx 10 bude užitečným příkazem. „Ukáže vám využití na místních pevných discích. Pokud to můžete spustit na souborovém serveru, řekne vám, jak je souborový server zaneprázdněn.

Obecným řešením bude zrychlete toto úzké místo, na které samozřejmě nemáte rozpočet. Existuje však několik zvláštních případů, kdy můžete najít rychlejší přístup:

• Pokud jsou soubory komprimovatelné, a máte rychlý procesor, provádění minimální komprese za chodu může být rychlejší. Něco jako lzop nebo možná gzip --fastest.
• Pokud měníte jen pár bitů sem a tam a poté odesíláte soubor zpět, bude posílání delt mnohem rychlejší. Bohužel rsync zde opravdu nepomůže, protože k nalezení delty bude nutné přečíst soubor na obou stranách. Místo toho potřebujete něco, co sleduje deltu při změně souboru … Většina přístupů je zde specifická pro konkrétní aplikaci. Je ale možné, že byste něco mohli vybavit, např. Mapovačem zařízení (viz zcela nový cíl dm-era ) nebo btrfs.
• Pokud kopírujete stejná data na více strojů, můžete je použít jako udpcast a odeslat je na všechny počítače najednou.

A, protože si všimnete, že nejste sysadmin, hádám, že to znamená, že máte sysadmina. Nebo alespoň někoho odpovědného za & síť souborového serveru. Pravděpodobně byste se ho měli zeptat / oni / oni, měli by být mnohem více obeznámeni se specifiky vašeho nastavení. Vaši administrátoři by měli být alespoň schopni vám říci, jakou přenosovou rychlost můžete rozumně očekávat.

Komentáře

• +1 pro iostat -kx 10 🙂

Může to být možná rychlejší alternativa a nebudete dva dny ucpávat síť: Vezměte jeden nebo dva velké disky USB (pokud máte USB 3) nebo FireWire, připojte je k na server a zkopírujte soubory na disk. Přeneste disk do místního počítače. Zkopírujte soubory do zařízení.

Komentáře

• Sneakernet ( en.wikipedia.org/ wiki / Sneakernet ) může být velmi rychlý: Nikdy nepodceňujte šířku pásma kombi plného pásek řítících se po dálnici.

Pokud máte přímý přístup SSH (nebo SFTP) (zeptejte se svého sysadmina), můžete použít scp s kompresí (-C):

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

To je samozřejmě užitečné pouze v případě, že je soubor komprimovatelný, a to bude vyžadovat více času CPU, protože bude používat šifrování (protože je to přes SSH) a komprimovat.

Komentáře

• V tomto případě by bylo užitečné deaktivovat šifrování. Pamatujte, že se snažíme kopii zrychlit .
• @lgeorget Mám podezření, že režie šifrování nebude ‚ t významná , vzhledem k tomu, jak pomalé jsou pevné disky. Zvažoval jsem přidání něčeho o -c none, ale to se zdá být nestandardní .
• ‚ řešíme ~ 20G soubory, takže je docela neefektivní používat šifrování, pokud to není nutné.
• @lgeorget Encryption může být udělal mnohem rychleji než propustnost, kterou ‚ získává, takže to ‚ nic nezpomalilo. Ale zdá se zbytečné projít SSH zde. Pokud potřebujete komprimaci, určitě existují i jiné nástroje?
• @Thomas Výhodou SSH je, že pokud ‚ byste měli mít přístup ke vzdálenému serveru, pak ‚ téměř jistě běží SSH. Další možností by bylo komprimovat soubor lokálně, zkopírovat jej na server, poté ssh a dekomprimovat jej.

Vaše definice efektivního řešení je zpětná. Efektivnější implementace plýtvá méně času procesoru. Na lokální kopii dosahujete průměrné propustnosti asi 74 MB / s (čtení + zápis), což je zhruba stejně dobrá úroveň jako na jednom pevném disku.

Komentáře

• Jejda.Když jsem řekl “ efektivní, “ jsem myslel “ rychle. “

cp implementace s největší pravděpodobností není překážkou. Zkuste sledovat využití IO pomocí iotop na serveru i uzlu clusteru. Tím získáte představu, kde můžete zlepšit výkon.

Dalším tipem je vyhnout se kopírování stejných dat ze stejného hostitele. Například pokud máte identický soubor 20G k distribuci ze souborového serveru přes síť do všech uzlů clusteru, bude to fungovat mnohem rychleji, než když budete kopírovat soubory způsobem peer-to-peer, spíše než mezi klienty typu každý server. Implementace je trochu komplikovanější, ale můžete se dokonce pokusit použít nějaký p2p z příkazové řádky, jako je hub pro přímé připojení.

Pokud je v rámci těchto souborů 20G některá část běžná a některé jsou specifické pro uzel clusteru, zvažte rozdělit na běžné a konkrétní části a poté distribuovat společnou část způsobem p2p.

Komentáře

• Pokud ‚ Pokud používáte LAN, měli byste být schopni provádět multicast místo peer-to-peer. Což by mělo být rychlejší a menší zatížení sítě.

Povaha / obsah těchto souborů může něco změnit. Pochopil jsem, že je třeba zkopírovat 200 souborů, každý po 20 GB, z jednoho počítače do druhého. Je to tak?

Pokud jsou tyto soubory komprimovatelné nebo s podobnými / stejnými kousky, máte dva přístupy:

• před kopírováním je zazipujte nebo vytvořte tunel mezi počítači se zapnutým zipem. Pokud je tedy síť úzkým hrdlem, bude to trochu faste r

• pokud jsou soubory velmi podobné nebo pokud mezi nimi sdílíte některé části společného obsahu, zkuste použít rsync . „Strávím nějaký čas hledáním toho, co je mezi soubory běžné, a nebudeme to muset zkopírovat doslovně , protože to„ zrekonstruujeme podle toho, co je běžné “.

úprava

Budete tyto soubory muset mnohokrát kopírovat ?? (jako kopii -> použít tyto soubory -> změnit něco v souborech v počítači A -> zkopírovat soubory znovu do počítače B)

Pokud ano, rsync bude užitečný, protože se „pokusí zjistit, co je mezi verzemi stejné, a nekopíruje to, co se nemění.

A třetí metoda: pokud je výše uvedené správné (změny v souboru, pak všechny soubory zkopírujte znovu do druhého počítače), můžete zkusit binary diff pouze změna v druhém počítači, co bylo změněno v prvním počítači.

Vidím zde následující, šifrování není dobrý nápad, protože by to mohlo ZVÝŠIT množství přenesených dat.

Pokud kopírujete mezi dvěma systémy, pak je samozřejmě úzké místo t Spojení mezi servery.

Pokud kopírujete lokálně, podívejte se, jak tento proces probíhá, je to SINGLE threaded, tedy standardní linuxové nástroje používají:

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

S touto operací NENÍ souběžnost.

Chcete-li věci urychlit, můžete použít něco podobného:

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

Další informace najdete na stránce manuálu bufferu (1).

Příkaz bufferu nastavuje dva procesy pro souběžné spuštění procesu kopírování: jeden pro čtení a druhý pro zápis a ke komunikaci dat mezi těmito dvěma procesy používá vyrovnávací paměť sdílené paměti. Vyrovnávací paměť sdílené paměti je vaše klasická kruhová vyrovnávací paměť, která zabraňuje přepsání nenapsaných dat a zápisu již zapsaných dat. Tento program jsem použil k odříznutí přibližně 10–20% času kopírování při přenosu z disku na pásku.

Komentáře

• Ve skutečnosti existuje souběžnost v “ čtení bloku / zápis bloku “ protože “ zápis bloku “ ve skutečnosti to vloží do vyrovnávací paměti jádra ‚ a jádro zvládne zápis skutečného bloku na pozadí (alespoň, dokud začít docházet RAM). Nebo pokud z nějakého důvodu používáte O_DSYNC / O_SYNC.

Proč nezkusit algoritmus šíření P2P , pokud potřebujete aktualizovat celý svůj klastr současně?

https://github.com/lg/murder je jaké twitter používá

Můžete také vyzkoušet BTSync .

Pokud často kopírujete stejné sady souborů z místního počítače na server s malými změnami sem a tam. Přenos můžete urychlit pomocí rsync nebo DVCS (např. Hg nebo git).

git nebo hg mohou sledovat a detekovat delty a přenášet pouze tyto delty. V případě použití git, protože obě strany mají plnou historii úložiště, je zjištění delty velmi levné.

rsync používá k detekci delt formu algoritmu průběžného kontrolního součtu bez předchozí znalosti toho, co je na druhé straně. Výpočet delt rsnc sice vyžaduje více práce, ale nemusí ukládat celý historie souborů.

Možná budete chtít zkusit zabalit všechny soubory do jednoho archivu (nemusí být komprimován). Podle mých zkušeností je kopírování jednoho archivu rychlejší než kopírování velkého počtu jednotlivých souborů.

Komentáře

• Dobré obecné pozorování, ale jak říká otázka „~ 200 velkých souborů – každý ~ 20 GB“, nevěřím, ‚ že to lze považovat za skutečnou odpověď na tento problém.
• @manatwork ah .. nečetl jsem ‚ jasně. Myslel jsem, že má 200 souborů o celkové velikosti 20 GB

Zkuste bbcp . Testování v našem prostředí odhalilo, že cp má něco o f zabudovaný regulátor. Jen buďte opatrní, protože když sundáte guvernéra, můžete svůj server přesměrovat a způsobit výpadek. V našem případě jsme kvůli kopírování přepínali server do režimu offline, takže rychlejší bylo lepší. Tím se zlepšila doba přenosu o několik hodin.

Ujistěte se, že cíl soubory před kopírováním neexistují.

Někdy je překvapivé, kolik času stráví i jen kopírování na stejného hostitele (není zapojena žádná síť).

Viz moji odpověď na další otázku CP zde . Stručně řečeno, přepsání existujícího souboru je mnohem pomalejší než jeho zkrácení nebo první odpojení, a poté kopírování. Ten je u souboru 1,2 GB 8krát rychlejší.