Is er een sneller alternatief voor cp voor het kopiëren van grote bestanden (~ 20 GB)?

% CPU zou laag moeten zijn tijdens het kopiëren. De CPU vertelt de schijfcontroller “gegevens uit sectoren X – Y in geheugenbuffer op Z” te nemen. Dan gaat het en doet iets anders (of slapen, als er niets anders is). De hardware activeert een interrupt wanneer de gegevens in het geheugen staan. Vervolgens moet de CPU het een paar keer kopiëren, en vertelt de netwerkkaart “verzend pakketten op geheugenlocaties A, B en C”. Daarna gaat het weer iets anders doen.

Je pusht ~ 240mbps.Op een gigabit LAN zou je minimaal 800 Mbps moeten kunnen doen, maar:

1. Dat wordt gedeeld door iedereen die de bestandsserver gebruikt (en mogelijk een verbinding tussen schakelaars, enz.)
2. Dat wordt beperkt door de snelheid waarmee de bestandsserver het schrijven aankan, rekening houdend met de I / O-bandbreedte van de schijf wordt gedeeld door iedereen die er gebruik van maakt.
3. Je hebt niet gespecificeerd hoe je hebt toegang tot de bestandsserver (NFS, CIFS (Samba), AFS, etc.). Mogelijk moet u uw netwerkkoppeling aanpassen, maar op alles wat half recent is, zijn de standaardwaarden meestal redelijk redelijk.

Voor het opsporen van de bottleneck, iostat -kx 10 wordt een handig commando. Het zal u het gebruik op uw lokale harde schijven laten zien. Als u dat op de bestandsserver kunt uitvoeren, zal het u vertellen hoe druk de bestandsserver is.

De algemene oplossing zal zijn om versnel die bottleneck, waarvoor je natuurlijk geen budget hebt. Maar er zijn een paar speciale gevallen waarin je een snellere aanpak kunt vinden:

• Als de bestanden comprimeerbaar zijn, en je hebt een snelle CPU, dus een minimale compressie kan sneller zijn. Iets als lzop of misschien gzip --fastest.
• Als u slechts hier en daar een paar bits wijzigt en het bestand vervolgens terugstuurt, gaat alleen het verzenden van deltas veel sneller. Helaas rsync zal hier niet echt helpen, omdat het het bestand aan beide kanten moet lezen om de delta te vinden. In plaats daarvan heb je iets nodig dat de delta bijhoudt terwijl je het bestand wijzigt … De meeste benaderingen hier zijn app-specifiek. Maar het is mogelijk dat u iets kunt manipuleren met bijvoorbeeld device-mapper (zie het gloednieuwe doel uit het dm-tijdperk ) of btrfs.
• Als je dezelfde gegevens naar meerdere machines kopieert, kun je zoiets als udpcast gebruiken om het naar alle machines tegelijk te sturen.

En, aangezien je merkt dat je “niet de sysadmin bent, vermoed ik dat dit betekent dat je een sysadmin hebt. Of in ieder geval iemand die verantwoordelijk is voor de bestandsserver & netwerk. Je zou hem / zij / zij zouden veel meer vertrouwd moeten zijn met de details van uw setup. Uw sysadmin (s) zouden u in ieder geval moeten kunnen vertellen welke overdrachtssnelheid u redelijkerwijs kunt verwachten.

Opmerkingen

• +1 voor iostat -kx 10 🙂

Dit zou mogelijk een sneller alternatief kunnen zijn, en u zult het netwerk gedurende twee dagen niet verstoppen: neem een of twee grote USB- (USB 3 als u die hebt) of FireWire-schijven, sluit deze aan op de server en kopieer de bestanden naar de schijf. Draag de schijf naar uw lokale computer. Kopieer de bestanden naar de machine.

Opmerkingen

• Sneakernet ( en.wikipedia.org/ wiki / Sneakernet ) kan erg snel zijn: onderschat nooit de bandbreedte van een stationwagen vol banden die over de snelweg raast.

Als je directe SSH (of SFTP) -toegang hebt (vraag het je sysadmin), kun je scp gebruiken met compressie (-C):

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

Natuurlijk is dat alleen nuttig als het bestand comprimeerbaar is, en dit zal meer CPU-tijd in beslag nemen, aangezien het zal codering gebruiken (omdat het over SSH gaat) en comprimeren.

Reacties

• In dit geval zou het handig zijn om uit te schakelen de versleuteling. Onthoud dat we proberen de kopie sneller te maken.
• @lgeorget Ik vermoed dat de overhead van de codering ‘ niet significant zal zijn gezien hoe traag harde schijven zijn. Ik heb overwogen iets toe te voegen over -c none, maar dat lijkt niet-standaard .
• We ‘ hebben te maken met ~ 20G-bestanden, dus het is vrij inefficiënt om encryptie te gebruiken als deze niet nodig is.
• @lgeorget Encryption kan zijn veel sneller gedaan dan de doorvoer die hij ‘ krijgt, dus het zal ‘ niets vertragen. Maar het lijkt niet nodig om hier via SSH te gaan. Als je alleen compressie nodig hebt, zijn er zeker andere tools?
• @Thomas Het voordeel van SSH is dat als je ‘ toegang zou moeten hebben tot de externe server, dan ‘ draait vrijwel zeker SSH. Een andere optie zou zijn om het bestand lokaal te comprimeren, het naar de server te kopiëren, vervolgens ssh erin te zetten en het uit te pakken.

Uw definitie van efficiënt is achterstevoren. Een efficiëntere implementatie verspilt minder cpu-tijd. Op de lokale kopie ben je gemiddeld ongeveer 74 MB / s aan doorvoer (lezen + schrijven), wat ongeveer net zo goed is als een enkele harde schijf kan krijgen.

Opmerkingen

• Oeps.Toen ik ” efficiënt, ” zei, bedoelde ik ” snel. ”

De cp implementatie is hoogstwaarschijnlijk geen bottleneck. Probeer het IO-gebruik te observeren via iotop op zowel de server als het clusterknooppunt. Dit geeft u een idee waar u de prestaties kunt verbeteren.

Een andere tip is om te voorkomen dat u dezelfde gegevens van dezelfde host kopieert. Als u bijvoorbeeld een identiek 20G-bestand heeft om vanaf de fileserver over het netwerk naar alle clusterknooppunten te distribueren, werkt het veel sneller als u bestanden op peer-to-peer-wijze kopieert in plaats van één server-naar-alle-clients. Het is wat ingewikkelder om te implementeren, maar je kunt zelfs proberen om een p2p-opdrachtregel te gebruiken, zoals een direct connect hub.

Als binnen die 20G-bestanden een deel gebruikelijk is en sommige clusterknooppuntspecifiek, overweeg dan het opsplitsen in algemene en specifieke delen en vervolgens het gemeenschappelijke deel op p2p-manier distribueren.

Opmerkingen

• Als je ‘ re op een LAN, zou je in staat moeten zijn om multicast te doen in plaats van peer-to-peer. Dit zou sneller moeten zijn en minder belasting van het netwerk.

De aard / inhoud van die bestanden kan enig verschil maken. Ik begreep dat je 200 bestanden, elk ~ 20 GB, van de ene computer naar de andere moet kopiëren , is dat het?

Als die bestanden comprimeerbaar zijn of met vergelijkbare / identieke stukken, heb je twee benaderingen:

• zip ze voordat je ze kopieert, of maak een tunnel tussen de computers met zip ingeschakeld. Dus als het netwerk de bottleneck is, zal het een beetje snel zijn r

• als de bestanden erg op elkaar lijken, of een aantal gemeenschappelijke inhoud met elkaar delen, probeer dan rsync . Het zal wat tijd besteden aan het zoeken naar wat gebruikelijk is in de bestanden, en het zal niet letterlijk hoeven te kopiëren, omdat het het reconstrueert op basis van wat algemeen is.

bewerken

Moet je die bestanden vaak kopiëren ?? (zoals een kopie -> gebruik die bestanden -> verander iets in de bestanden in de computer A -> kopieer bestanden opnieuw naar computer B)

Als dat zo is, zal rsync nuttig zijn, omdat het “zal proberen te detecteren wat gelijk is tussen de versies en niet zal kopiëren wat ongewijzigd is.

En een derde methode: als het bovenstaande correct is (wijzigingen in bestand, kopieer dan alle bestanden opnieuw naar de tweede computer), zou je wat binary diff kunnen proberen om alleen verandering in de tweede computer wat er in de eerste computer is gewijzigd.

Ik zie hier het volgende, codering is geen goed idee, want het kan de hoeveelheid over te dragen gegevens VERGROTEN.

Als u tussen twee systemen kopieert, is de bottleneck natuurlijk t de verbinding tussen de servers.

Als je lokaal kopieert, kijk dan hoe het proces verloopt, het is ENKEL threaded, dus gebruiken standaard Linux-hulpprogrammas:

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

Er is GEEN gelijktijdigheid met deze bewerking.

Om dingen te versnellen kun je zoiets als dit gebruiken:

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

Zie de buffer (1) man-pagina voor meer informatie.

Het buffercommando stelt twee processen in om het kopieerproces gelijktijdig uit te voeren: een voor lezen en een voor schrijven, en het gebruikt een gedeelde geheugenbuffer om de gegevens tussen de twee processen te communiceren. De gedeelde geheugenbuffer is uw klassieke circulaire buffer die het overschrijven van ongeschreven gegevens en het schrijven van reeds geschreven gegevens voorkomt. Ik heb dit programma gebruikt om ongeveer 10-20% van de kopieertijd in overdrachten van schijf naar tape te verkorten.

Opmerkingen

• Eigenlijk is er concurrency in ” lees een blok / schrijf een blok ” omdat ” schrijf een blok ” plaatst het eigenlijk gewoon in de kernel ‘ s buffer, en de kernel handelt het daadwerkelijke blok schrijven op de achtergrond af (tenminste, totdat je beginnen met bijna zonder RAM). Of als u om de een of andere reden O_DSYNC / O_SYNC gebruikt.

Probeer eens een P2P-propagatie-algoritme , als u uw hele cluster tegelijkertijd moet bijwerken?

https://github.com/lg/murder is wat twitter gebruikt

Er is BTSync die u ook kunt proberen.

Als u “dezelfde sets bestanden regelmatig van uw lokale computer naar de server kopieert met hier en daar kleine wijzigingen. U kunt de overdracht versnellen door rsync of een DVCS te gebruiken (bijv. Hg of git).

git of hg kunnen deltas bijhouden en detecteren en alleen die deltas overdragen. In het geval van het gebruik van een git, aangezien beide partijen een volledige geschiedenis van de repository hebben, is het uitzoeken van de delta erg goedkoop.

rsync gebruikt een vorm van rollend checksumming-algoritme om deltas te detecteren zonder voorafgaande kennis van wat er aan de andere kant is. Hoewel het meer werk kost voor rsync om de deltas te berekenen, hoeft het niet de hele bestandsgeschiedenis.

Misschien wil je proberen alle bestanden in een enkel archief te verpakken (hoeft niet te worden gecomprimeerd). In mijn ervaring is het kopiëren van dat ene archief sneller dan het kopiëren van een groot aantal individuele bestanden.

Opmerkingen

• Goede algemene observatie, maar zoals de vraag zegt “~ 200 grote bestanden – elk ~ 20 GB”, ik denk niet dat ‘ niet kan worden beschouwd als een echt antwoord op dit probleem.
• @manatwork ah .. ik heb ‘ niet duidelijk gelezen. Ik dacht dat hij 200 bestanden had van in totaal 20 GB

Probeer bbcp . Testen in onze omgeving lieten zien dat cp een soort o f ingebouwd governer. Wees voorzichtig, want wanneer u de beheerder uitschakelt, kunt u uw server opnieuw instellen en een storing veroorzaken. In ons geval haalden we de server offline om de kopie te doen, dus sneller was beter. Deze verbeterde overdrachtstijd van enkele uren.

Zorg ervoor dat het doel bestanden bestaan niet voordat ze worden gekopieerd.

Soms is het verrassend hoeveel tijd er wordt besteed aan het kopiëren op dezelfde host (zonder netwerk).

Zie mijn antwoord op een andere cp-vraag hier . Om een lang verhaal kort te maken, het overschrijven van een bestaand bestand is veel langzamer dan het eerst afkappen of ontkoppelen, en vervolgens kopiëren. Dit laatste is 8x sneller voor een bestand van 1,2 GB.