Esiste unalternativa più veloce a cp per copiare file di grandi dimensioni (~ 20 GB)?

% CPU dovrebbe essere bassa durante una copia. La CPU dice al controller del disco “preleva i dati dai settori X – Y nel buffer di memoria in Z”. Poi va e fa qualcosaltro (o dorme, se non cè nientaltro). Lhardware attiva un interrupt quando i dati sono in memoria. Quindi la CPU deve copiarlo alcune volte e dice alla scheda di rete “trasmettere i pacchetti nelle posizioni di memoria A, B e C”. Quindi si torna a fare qualcosaltro.

Stai spingendo ~ 240 Mbps.Su una LAN gigabit, dovresti essere in grado di fare almeno 800 Mbps, ma:

1. Questo è condiviso tra tutti coloro che utilizzano il file server (e possibilmente una connessione tra switch, ecc.)
2. Questo è limitato dalla velocità che il file server può gestire in scrittura, tenendo presente che la sua larghezza di banda di I / O del disco è condivisa da chiunque lo utilizzi.
3. Non hai specificato come stai accedendo al file server (NFS, CIFS (Samba), AFS, ecc.). Potrebbe essere necessario regolare il montaggio della rete, ma su qualsiasi cosa recente a metà le impostazioni predefinite sono generalmente abbastanza corrette.

Per individuare il collo di bottiglia, iostat -kx 10 sarà un comando utile. Ti mostrerà lutilizzo sui tuoi dischi rigidi locali. Se puoi eseguirlo sul file server, ti dirà quanto è occupato il file server.

La soluzione generale sarà quella di accelera quel collo di bottiglia, per il quale ovviamente non hai il budget. Tuttavia, ci sono un paio di casi speciali in cui puoi trovare un approccio più veloce:

• Se i file sono comprimibili, e hai una CPU veloce, eseguire una compressione minima al volo potrebbe essere più veloce. Qualcosa come lzop o forse gzip --fastest.
• Se modifichi solo alcuni bit qua e là e poi rispedisci il file, solo linvio di delta sarà molto più veloce. Sfortunatamente, rsync non sarà di grande aiuto qui, poiché sarà necessario leggere il file su entrambi i lati per trovare il delta. Invece, hai bisogno di qualcosa che tenga traccia del delta mentre modifichi il file … La maggior parte degli approcci qui sono specifici dellapp. Ma è possibile che tu possa creare qualcosa con, ad esempio, device-mapper (vedi il nuovissimo dm-era target ) o btrfs.
• Se “stai copiando gli stessi dati su più macchine, puoi usare qualcosa come udpcast per inviarlo a tutte le macchine contemporaneamente.

E, dato che noti che “non sei lamministratore di sistema, immagino che questo significhi che hai un amministratore di sistema. O almeno qualcuno responsabile della rete del file server &. Probabilmente dovresti chiedergli / lei / loro, dovrebbero avere molta più familiarità con le specifiche della tua configurazione. Il tuo amministratore di sistema dovrebbe almeno essere in grado di dirti quale velocità di trasferimento puoi ragionevolmente aspettarti.

Commenti

• +1 per iostat -kx 10 🙂

Questa potrebbe, forse, essere unalternativa più veloce e non intaserai la rete per due giorni: prendi uno o due grandi dischi USB (USB 3 se ce lhai) o FireWire, collegalo a il server e copiare i file sul disco. Porta il disco sul tuo computer locale. Copia i file sulla macchina.

Commenti

• Sneakernet ( en.wikipedia.org/ wiki / Sneakernet ) può essere molto veloce: non sottovalutare mai la larghezza di banda di una station wagon piena di nastri che sfrecciano lungo lautostrada.

Se disponi di un accesso SSH (o SFTP) diretto (chiedi al tuo amministratore di sistema), puoi utilizzare scp con compressione (-C):

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

Ovviamente, è utile solo se il file è comprimibile e utilizzerà più tempo CPU, poiché utilizzerà la crittografia (perché è su SSH) e la compressione.

Commenti

• In questo caso, sarebbe utile disabilitare la crittografia. Ricorda che stiamo cercando di rendere la copia più veloce .
• @lgeorget Sospetto che il sovraccarico della crittografia ‘ non sia significativo , considerando quanto sono lenti i dischi rigidi. Ho pensato di aggiungere qualcosa su -c none, ma sembra non essere standard .
• ‘ ci occupiamo di file ~ 20G, quindi è piuttosto inefficiente usare la crittografia se non necessaria.
• @lgeorget Encryption può essere fatto molto più velocemente del throughput che ‘ ottiene, quindi ‘ non rallenta nulla. Ma non sembra necessario passare tramite SSH qui. Se hai solo bisogno della compressione, sicuramente ci sono altri strumenti?
• @Thomas Il vantaggio di SSH è che se ‘ dovresti avere accesso al server remoto, quindi ‘ quasi certamente esegue SSH. Unaltra opzione potrebbe essere quella di comprimere il file localmente, copiarlo sul server, quindi ssh e decomprimerlo ..

La tua definizione di efficiente è al contrario. Unimplementazione più efficiente fa perdere meno tempo alla CPU. Sulla copia locale stai calcolando una media di circa 74 MB / s di velocità effettiva (lettura + scrittura), che è più o meno quella che otterrebbe un singolo disco rigido.

Commenti

• Oops.Quando ho detto ” efficiente, ” intendevo ” veloce. ”

Il cp molto probabilmente limplementazione non è un collo di bottiglia. Prova a osservare lutilizzo di IO tramite iotop sia sul server che sul nodo del cluster. Questo ti darà unidea di dove puoi migliorare le prestazioni.

Un altro suggerimento è evitare di copiare gli stessi dati dallo stesso host. Ad esempio, se si dispone di un file 20G identico da distribuire dal file server sulla rete a tutti i nodi del cluster, funzionerà molto più velocemente se si copiano i file in modalità peer-to-peer piuttosto che da un server a tutti i client. È un po più complicato da implementare, ma puoi anche provare a utilizzare un p2p a riga di comando come lhub di connessione diretta.

Se allinterno di quei file 20G, alcune parti sono comuni e alcune sono specifiche del nodo del cluster, considera suddividendolo in parti comuni e specifiche, quindi distribuire la parte comune in modo p2p.

Commenti

• Se ‘ su una LAN, dovresti essere in grado di fare multicast invece di peer-to-peer. Che dovrebbe essere più veloce e meno carico sulla rete.

La natura / i contenuti di questi file possono fare la differenza. Ho capito che devi copiare 200 file, circa 20 GB ciascuno, da un computer a un altro , è così?

Se quei file sono comprimibili o con parti simili / identiche, hai due approcci:

• comprimili prima di copiarli o crea un tunnel tra i computer con zip abilitato su di esso. Quindi, se la rete è il collo di bottiglia, sarà un po faste r

• se i file sono molto simili, o condividono tra loro alcuni pezzi di contenuto comune, prova a utilizzare rsync . Passerà un po di tempo a trovare ciò che è comune tra i file e non sarà necessario copiarlo letteralmente , perché lo ricostruirà in base a ciò che è comune.

edit

Dovrai copiare quei file molte volte ?? (come una copia -> usa quei file -> cambia qualcosa nei file nel computer A -> copia di nuovo i file sul computer B)

Se è così, rsync sarà utile, perché proverà a rilevare ciò che è uguale tra le versioni e non copierà ciò che è invariato.

E un terzo metodo: se quanto sopra è corretto (modifiche nel file, quindi copia di nuovo tutti i file sul secondo computer) potresti provare con binary diff solo cambiare nel secondo computer ciò che è stato cambiato nel primo computer.

Vedo quanto segue qui, la crittografia non è un buona idea in quanto potrebbe AUMENTARE la quantità di dati da trasferire.

Se stai copiando tra due sistemi, il collo di bottiglia è ovviamente t la connessione tra i server.

Se stai copiando localmente, guarda come va il processo, è a thread SINGOLO, quindi le utility Linux standard usano:

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

NON cè concorrenza per questa operazione.

Per velocizzare le cose puoi usare qualcosa del genere:

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

Vedi la pagina man buffer (1) per maggiori informazioni.

Il comando buffer imposta due processi per eseguire il processo di copia contemporaneamente: uno per la lettura e laltro per la scrittura, e utilizza un buffer di memoria condiviso per comunicare i dati tra i due processi. Il buffer di memoria condivisa è il classico buffer circolare che impedisce la sovrascrittura di dati non scritti e la scrittura di dati già scritti. Ho usato questo programma per tagliare circa il 10-20% del tempo di copia nei trasferimenti da disco a nastro.

Commenti

• In realtà, cè concorrenza in ” leggere un blocco / scrivere un blocco ” perché ” scrivere un blocco ” in realtà lo inserisce nel buffer del ‘ e il kernel gestisce leffettivo blocco di scrittura in background (almeno, finché non iniziare a esaurire la RAM). O se stai usando O_DSYNC / O_SYNC per qualche motivo.

Perché non provare un algoritmo di propagazione P2P , se devi aggiornare lintero cluster contemporaneamente?

https://github.com/lg/murder è cosa usa Twitter

Cè “s BTSync che puoi provare anche tu.

Se stai copiando frequentemente gli stessi set di file dal tuo computer locale al server con piccole modifiche qua e là. Puoi accelerare il trasferimento usando rsync o un DVCS (es. Hg o git).

git o hg possono tenere traccia e rilevare i delta e trasferire solo quei delta. In caso di utilizzo di un git, poiché entrambe le parti hanno una cronologia completa del repository, capire il delta è molto economico.

rsync utilizza una forma di algoritmo di checksum a rotazione per rilevare i delta senza conoscere in anticipo cosa cè dallaltra parte. Sebbene rsync richieda più lavoro per calcolare i delta, non ha bisogno di memorizzare lintero cronologia dei file.

Potresti provare a impacchettare tutti i file in un unico archivio (non è necessario comprimerli). Nella mia esperienza, copiare quellarchivio è più veloce che copiare un gran numero di singoli file

Commenti

• Buona osservazione generica, ma come dice la domanda “~ 200 file di grandi dimensioni – ciascuno ~ 20 GB”, non ‘ credo che questa possa essere considerata una risposta effettiva a questo problema.
• @manatwork ah .. non ‘ ho letto chiaramente. Pensavo avesse 200 file per un totale di 20 GB

Prova bbcp . I test nel nostro ambiente hanno rivelato che cp aveva una sorta di o f costruito nel governatore. Fai solo attenzione perché quando decolli il governatore, puoi mettere la linea rossa sul tuo server e causare uninterruzione. Nel nostro caso stavamo portando il server offline per eseguire la copia, quindi più veloce era meglio. Questo ha migliorato il tempo di trasferimento di diverse ore.

Assicurati che il target i file non esistono prima della copia.

A volte è sorprendente quanto tempo viene speso anche solo per copiare sullo stesso host (nessuna rete coinvolta).

Vedi la mia risposta a unaltra domanda cp qui . Per farla breve, sovrascrivere un file esistente è molto più lento che troncarlo o scollegarlo prima, e poi la copia. Questultima è 8 volte più veloce per un file da 1,2 GB.