Er det et raskere alternativ til cp for kopiering av store filer (~ 20 GB)?

Dette kan muligens være et raskere alternativ, og du vil ikke tette nettverket i to dager: Ta en eller to store USB (USB 3 hvis du har det) eller FireWire-disker, koble den til serveren og kopier filene til disken. Bær disken til din lokale maskin. Kopier filene til maskinen.

Kommentarer

• Sneakernet ( en.wikipedia.org/ wiki / Sneakernet ) kan være veldig rask: Undervurder aldri båndbredden til en stasjonsvogn full av bånd som slynger seg nedover motorveien.

Hvis du har direkte SSH (eller SFTP) tilgang (spør sysadmin), kan du bruke scp med komprimering (-C):

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

Selvfølgelig er det bare nyttig hvis filen er komprimerbar, og dette vil bruke mer CPU-tid siden det vil bruke kryptering (fordi det er over SSH), og komprimering.

Kommentarer

• I dette tilfellet vil det være nyttig å deaktivere krypteringen. Husk at vi prøver å gjøre kopien raskere .
• @lgeorget Jeg mistenker at kostnaden for krypteringen ikke vil være ‘ t være betydelig , med tanke på hvor sakte harddisker er. Jeg vurderte å legge til noe om -c none, men at ser ut til å være ikke-standard .
• Vi ‘ har å gjøre med ~ 20G-filer, så det er ganske ineffektivt å bruke kryptering hvis det ikke er nødvendig.
• @lgeorget Kryptering kan være gjort langt raskere enn gjennomstrømningen han ‘ får, så det vant ‘ t å senke noe. Men det virker unødvendig å gå gjennom SSH her. Hvis du bare trenger komprimering, finnes det sikkert andre verktøy?
• @Thomas Fordelen med SSH er at hvis du ‘ skal ha tilgang til den eksterne serveren, så kjører det nesten helt sikkert ‘ SSH. Et annet alternativ vil være å komprimere filen lokalt, kopiere den til serveren, deretter ssh inn og dekomprimere den ..

Din definisjon av effektiv er bakover. En mer effektiv implementering kaster bort mindre CPU-tid. På den lokale kopien har du gjennomsnittlig 74 MB / s gjennomstrømning (les + skriv), noe som er omtrent like bra som en enkelt harddisk kommer til å bli.

Kommentarer

• Beklager.Da jeg sa » effektiv, » mente jeg » raskt. »

cp implementering er sannsynligvis ikke en flaskehals. Prøv å observere IO-bruk via iotop på både server og klyngenode. Dette vil gi deg en ide hvor du kan forbedre ytelsen.

Et annet tips er å unngå å kopiere samme data fra samme vert. For eksempel, hvis du har identisk 20G-fil å distribuere fra filserver over nettverket til alle klyngenoder, vil den fungere mye raskere enn hvis du kopierer filer på peer-to-peer-måte i stedet for en-server-til-alle-klienter. Det er litt mer komplisert å implementere, men du kan til og med prøve å bruke noen kommandolinje p2p som direktekoblingsnav. dele den opp i vanlige og spesifikke deler, og distribuer deretter felles del på p2p-måte.

Kommentarer

• Hvis du ‘ på et LAN, bør du kunne gjøre multicast i stedet for peer-to-peer. Hvilket skal være raskere og mindre belastning på nettverket.

Filenes art / innhold kan gjøre noen forskjell. Jeg forsto at du trenger å kopiere 200 filer, ~ 20 GB hver, fra en datamaskin til en annen , er det det?

Hvis disse filene er komprimerbare eller med lignende / identiske deler, har du to tilnærminger:

• zip dem før du kopierer, eller opprett en tunnel mellom datamaskiner med zip-aktivering på. Så hvis nettverket er flaskehalsen, vil det være litt fast r

• Hvis filene er veldig like, eller deler noen deler av vanlig innhold blant dem, kan du prøve å bruke rsync . Det vil bruke litt tid på å finne det som er vanlig blant filene, og trenger ikke å kopiere det bokstavelig fordi det vil rekonstruere det basert på det som er vanlig.

redigere

Trenger du å kopiere disse filene mange ganger ?? (som en kopi -> bruk disse filene -> endre noe i filene i datamaskinen A -> kopier filer på nytt til datamaskin B)

I så fall vil rsync være nyttig, fordi den vil prøve å oppdage hva som er likt blant versjonene og ikke kopiere det som er uendret.

Og en tredje metode: hvis det ovennevnte er riktig (endringer i filen, kopier deretter alle filene igjen til den andre datamaskinen) kan du prøve noen binary diff til bare endring i den andre datamaskinen hva som ble endret i den første datamaskinen.

Jeg ser følgende her, kryptering er ikke en god idé, da det muligens ØKER mengden data som skal overføres.

Hvis du kopierer mellom to systemer, er flaskehalsen selvsagt ikke forbindelsen mellom serverne.

Hvis du kopierer lokalt, se på hvordan prosessen går, den er ENKELT gjenget, så standard Linux-verktøy bruker:

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

Denne operasjonen har INGEN samtidighet.

For å øke hastigheten kan du bruke noe sånt som dette:

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

Se buffersiden (1) for mer informasjon.

Bufferkommandoen setter opp to prosesser for å kjøre kopieringsprosessen samtidig: den ene for lesing og den andre for skriving, og den bruker en delt minnebuffer for å kommunisere dataene mellom de to prosessene. Delt minnebuffer er din klassiske sirkulære buffer som forhindrer overskriving av uskrevne data og skriving av data som allerede er skrevet. Jeg har brukt dette programmet til å kutte av omtrent 10-20% av kopitiden i overføringer fra disk til tape.

Kommentarer

• Det er faktisk samtidighet i » les en blokk / skriv en blokk » fordi » skriv en blokk » setter den faktisk bare i kjernen ‘ s buffer, og kjernen håndterer den faktiske blokkeringen i bakgrunnen (i det minste, til du begynn å gå tom for RAM). Eller hvis du av en eller annen grunn bruker O_DSYNC / O_SYNC.

Hvorfor ikke prøve en P2P-formeringsalgoritme , hvis du trenger å oppdatere hele klyngen samtidig?

https://github.com/lg/murder er hva twitter bruker

Det er «s BTSync som du også kan prøve.

Hvis du ofte kopierer de samme settene med filer fra din lokale datamaskin til serveren med mindre endringer her og der. Du kan øke hastigheten på overføringen ved å bruke rsync eller en DVCS (f.eks. Hg eller git).

git eller hg kan holde oversikt og oppdage deltas og bare overføre deltas. I tilfelle du bruker en git, siden begge sider har full historie med depotet, er det veldig billig å finne ut deltaet.

rsync bruker en form for rullende sjekkummingsalgoritme for å oppdage deltas uten forhåndskunnskap om hva som er på den andre siden. Selv om det tar mer arbeid for rsync å beregne deltaene, trenger det ikke å lagre hele filhistorikk.

Det kan være lurt å prøve å pakke alle filene inn i ett arkiv (trenger ikke komprimeres). Etter min erfaring er å kopiere det ene arkivet raskere enn å kopiere et stort antall individuelle filer

Kommentarer

• God generisk observasjon, men som spørsmålet sier “~ 200 store filer – hver ~ 20 GB”, jeg tror ikke ‘ t dette kan betraktes som et faktisk svar på dette problemet.
• @manatwork ah .. jeg leste ikke ‘. Jeg trodde han hadde 200 filer på til sammen 20 GB

Prøv bbcp . Testing i vårt miljø avslørte at cp hadde en slags o f innebygd guvernør. Bare vær forsiktig fordi når du tar av guvernøren, kan du rødlinje serveren din og forårsake strømbrudd. I vårt tilfelle tok vi serveren offline for å lage kopien, så raskere var bedre. Denne forbedrede overføringstiden flere timer.

Sørg for at målet filer eksisterer ikke før kopiering.

Noen ganger er det overraskende hvor mye tid som brukes til og med bare å kopiere på samme vert (ingen nettverk involvert).

Se svaret mitt på et annet cp-spørsmål her . Kort fortelling, å overskrive en eksisterende fil er mye tregere enn å trunke den eller fjerne tilknytningen først, og deretter kopiering. Sistnevnte er 8 ganger raskere for en 1,2 GB-fil.