Vraag Hoe een groot aantal bestanden snel tussen twee servers te kopiëren


Ik moet een enorme hoeveelheid mp3's overbrengen tussen twee diensten (Ubuntu). Met enorm bedoel ik ongeveer een miljoen bestanden die gemiddeld 300K zijn. Ik heb geprobeerd met scp maar het zou ongeveer een week hebben geduurd. (ongeveer 500 KB / s) Als ik een enkel bestand via HTTP overdraag, krijg ik 9-10 MB / s, maar ik weet niet hoe ik ze allemaal moet overdragen.

Is er een manier om ze allemaal snel over te zetten?


81
2018-06-02 19:55


oorsprong


Wat voor soort netwerk heb je tussen de servers. Ik heb een GB Ethernet-crossover gebruikt tussen 1 netwerkkaart in elke machine. Ik ben heel goed doorgekomen in die configuratie met behulp van SCP - Jim Blizard
Misschien wil je onderzoeken waarom scp zo traag is. Het is misschien langzamer dan dingen als ftp vanwege de codering, maar het zou niet zo veel langzamer moeten zijn. - Zoredache
Ik heb er 100 mbps tussen. scp is langzamer voor de kleine bestanden (de meeste zijn klein) - nicudotro


antwoorden:


Ik zou tar aanraden. Wanneer de bestandsstructuren al vergelijkbaar zijn, voert rsync uit heel goed. Omdat rsync echter meerdere analyse-passen aan elk bestand doorgeeft en de wijzigingen vervolgens kopieert, is het veel langzamer dan tar voor de eerste kopie. Deze opdracht zal waarschijnlijk doen wat je wilt. Het kopieert de bestanden tussen de machines en bewaart zowel de rechten als de eigendommen van gebruikers en groepen.

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'

Volgens de reactie van Mackintosh hieronder is dit het commando dat je zou gebruiken voor rsync

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir

109
2018-06-02 20:04



+1 De tar-optie is veel efficiënter voor grote aantallen kleine bestanden, omdat zowel scp als rsync veel meer retourvluchten per bestand over het netwerk zullen hebben. - Sekenre
rsync werkte beter voor mij dan tar - nicudotro
Ook als je voldoende CPU beschikbaar hebt (aan beide kanten), maar (tenminste) een trage link tussen de hosts, is het misschien de moeite waard om compressie (gzip of bzip) in de tar-opdracht mogelijk te maken. - Vatine
@Jamie: Als u ssh-agent gebruikt, moet deze worden gebruikt. Gebruik anders gewoon de '-i'-optie om op te geven waar de privésleutel te vinden is. Zie de man-pagina voor details. - Scott Pack
@niXar The ~ escape-teken is alleen ingeschakeld als SSH een terminal gebruikt. Dit is niet het geval wanneer u een opdracht op afstand opgeeft (tenzij u de -t keuze). Dus uw zorg is ongeldig. - Gilles


Externe harde schijf en koerierlevering op dezelfde dag.


32
2018-06-02 20:00



Heh heh ... geen netwerktechnologie verslaat de bandbreedte van een stationcar vol met banden die 90 MPH doen, nietwaar? (snicker) Ik ging ervan uit dat hij in een LAN zat omdat hij zei dat hij 9-10 MB / sec met HTTP zou krijgen. - Evan Anderson
Ik krijg dat soort snelheid via internet, maar ik heb gewoon geluk in waar ik woon! Als het op een LAN is, dan nog goedkoper! - Adam
Ahh-- keek niet naar je locatie. Ja-- Ik heb gehoord dat de internetconnectiviteit in Korea behoorlijk spectaculair is. Ik ben hier vast in de VS en ben blij dat ik 900KB / sec over de 'netto ... - Evan Anderson
Ja, maar je kunt heerlijke burrito's krijgen terwijl je wacht tot een download voltooid is en er zijn maar ongeveer drie halfwaardige Mexicaanse restaurants, zelfs in Seoul ... - Adam


Ik zou rsync gebruiken.

Als je ze hebt geëxporteerd via HTTP met beschikbare directoryvermeldingen, zou je ook het argument wget en the - mirrors kunnen gebruiken.

Je ziet nu al dat HTTP sneller is dan SCP omdat SCP alles codeert (en dus bottlenecking op de CPU). HTTP en rsync gaan sneller omdat ze niet coderen.

Hier zijn enkele documenten over het instellen van rsync op Ubuntu: https://help.ubuntu.com/community/rsync

Die documenten hebben het over het tunnelen van rsync via SSH, maar als je alleen gegevens verplaatst op een privé-LAN, heb je geen SSH nodig. (Ik neem aan dat je een privé-LAN hebt. Als je 9-10MB / sec via internet krijgt, wil ik weten wat voor soort verbindingen je hebt!)

Hier zijn enkele andere zeer eenvoudige documenten waarmee u een relatieve onveilige rsync-server (zonder afhankelijkheid van SSH) kunt instellen: http://transamrit.net/docs/rsync/


16
2018-06-02 19:57



Hoewel SCP inderdaad een bepaalde CPU gebruikt voor het coderen van de gegevens, denk ik niet dat hij een 100% CPU-gebruik heeft, dus de CPU is geen bottleneck. Ik heb ook vaak opgemerkt dat SCP inefficiënt is als het gaat om snelle overdrachten. - Cristian Ciupitu
Aangezien hij 300K voor SCP en 9 MB voor HTTP zag, ging ik ervan uit dat een SCP-gerelateerde bottleneck (normaal CPU) in het spel kwam. Het zou echter zeker iets anders kunnen zijn. Zonder de hardware-specificaties van de betreffende machines te kennen, is dit moeilijk te zeggen. - Evan Anderson
rsync gebruikt vrijwel zeker ssh voor transport, omdat dit standaard gedrag is, dus alle overhead veroorzaakt door codering in scp zal ook aanwezig zijn in rsync - Daniel Lawson
"U ziet nu al dat HTTP sneller is dan SCP, omdat SCP alles codeert" → FOUT. Tenzij hij 10 jaar oude servers heeft, is hij niet gebonden aan deze taak. - niXar
@ RamazanPOLAT - Je hebt een opdrachtregel die te lang is. Geef de bestandsselectie anders op en het werkt prima voor u. Meestal kunt u gewoon de bronmap opgeven zonder een jokerteken aan het einde. U kunt ook de --include en --exclude argumenten om genuanceerder te worden. - Evan Anderson


Gebruik zonder veel discussie netcat, network swissarmy knife. Geen overheadprotocol, u kopieert direct naar de netwerkaansluiting. Voorbeeld

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -

14
2018-06-02 20:17



Helaas, van wat ik heb gemerkt, is netcat zeer inefficiënt, zelfs als dat niet zo zou zijn. - Cristian Ciupitu
Ik ben je aan het negeren omdat dit echt heel erg advies is. Er is één correct antwoord: rsync. Ik zou alle redenen kunnen noemen waarom het beter is, maar het zou niet op deze pagina passen, laat staan ​​dit kleine commentaarveld. - niXar
@niXar: als u slechts één bestand wilt overbrengen (u hoeft niet verder te synchroniseren), dan is tarpipe echt alles wat u nodig hebt. - Witiko
@niXar netcat is prima als je dit doet in een beveiligde omgeving zoals privé vlan en / of via VPN. - Lester Cheung


Met veel bestanden als je met rsync gaat, Ik zou proberen versie 3 of hoger aan beide kanten te krijgen. De reden is dat een kleinere versie elk bestand opsomt voordat het de overdracht start. De nieuwe functie wordt genoemd incrementele-recursie.

Een nieuw algoritme voor incrementele recursie   wordt nu gebruikt wanneer rsync aan het praten is         naar een andere 3.x-versie. Hiermee begint de overdracht sneller         (voordat alle bestanden zijn gevonden) en vereist veel minder geheugen.         Zie de --recursieve optie in de manpage voor enkele beperkingen.


8
2018-06-02 20:41





rsync, zoals anderen al hebben aanbevolen. Als de CPU-overhead van de codering een bottleneck is, gebruikt u een ander minder CPU-intensief algoritme, zoals kogelvis. Bijv. zoiets als

rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path


7
2018-06-02 20:56



+1 voor een punt over het wijzigen van het cijfer - Daniel Lawson
De CPU wordt geen bottleneck, tenzij je een 10G ethernet en een 10 jaar oude CPU hebt. - niXar
gewoon commentaar: cipher "-c arcfour" is sneller. - Arman
@niXar: Maar als u al een CPU-verbruikende taak op uw computer hebt, is dit een zorg. - Isaac


Toen ik een groot aantal bestanden kopieerde, ontdekte ik dat tools zoals tar en rsync inefficiënter zijn dan ze zouden moeten zijn vanwege de overhead van het openen en sluiten van veel bestanden. Ik heb een open source-tool geschreven met de naam fast-archiver die sneller is dan tar voor deze scenario's: https://github.com/replicon/fast-archiver; het werkt sneller door meerdere gelijktijdige bestandsbewerkingen uit te voeren.

Hier is een voorbeeld van fast-archiver vs. tar op een back-up van meer dan twee miljoen bestanden; fast-archiver duurt 27 minuten om te archiveren, versus tar duurt 1 uur en 23 minuten.

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps

Om bestanden over te zetten tussen servers, kun je fast-archiver met ssh gebruiken, zoals dit:

ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x

4
2017-08-26 20:51





Bij het verplaatsen van 80 TB gegevens (miljoenen kleine bestanden) gisteren, het overschakelen van rsync naar tar  bleek veel sneller te zijn, zoals we stopten met proberen

# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01

en is overgeschakeld naar tar in plaats daarvan...

# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/ 

Omdat deze servers zich op hetzelfde LAN bevinden, is de bestemming NFS-gekoppeld op het bronsysteem, dat de push uitvoert. Nee, het maakt het nog sneller, we hebben besloten om het niet te behouden atime van bestanden:

mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01

De onderstaande afbeelding toont het verschil tussen de verandering van rsync naar teer. Het was mijn baas idee en mijn collega beiden hebben het uitgevoerd en het geweldig gemaakt schrijven op zijn blog. Ik hou gewoon van mooie plaatjes. :)

rsync_vs_tar


3
2018-04-04 10:32



Een hacker die ik vertrouw, vertelt me ​​dat "tar over tc in plaats van nfs misschien zelfs sneller is". d.w.z. tar cf - directory | ttcp -t dest_machine van ftp.arl.mil/mike/ttcp.html - Philip Durbin
Onafhankelijke vraag, maar waar komt die grafiek vandaan? - CyberJacob


Ik gebruik de teer door netcat aanpak ook, maar ik gebruik het liever socat - veel meer kracht om te optimaliseren voor uw situatie - bijvoorbeeld door mss aan te passen. (Lach ook als je wilt, maar ik merk het socat argumenten gemakkelijker te onthouden omdat ze consistent zijn). Dus voor mij is dit de laatste tijd heel gewoon omdat ik dingen naar nieuwe servers heb verplaatst:

host1$ tar cvf - filespec | socat stdin tcp4:host2:portnum

host2$ socat tcp4-listen:portnum stdout | tar xvpf -

Aliassen zijn optioneel.


3
2018-06-03 06:38