Esiste un'alternativa più rapida a cp per la copia di file di grandi dimensioni (~ 20 GB)?

Sono uno studente laureato e il gruppo in cui lavoro mantiene un cluster Linux. Ogni nodo del cluster ha il proprio disco locale, ma questi dischi locali sono relativamente piccoli e non sono dotati di backup automatico. Quindi il gruppo possiede un file server con molti TB di spazio di archiviazione. Sono un novizio Linux relativo, quindi non sono sicuro di quali siano le specifiche del file server in termini di velocità, capacità di rete, ecc. So per esperienza che i dischi locali sono significativamente più veloci del file server in termini di I / O . Circa una dozzina di persone usano il file server.

L'uso cpper copiare un file di ~ 20 GB dal fileserver su uno dei dischi locali richiede in media circa 11,5 minuti in tempo reale (secondo time). So che questa cpoperazione non è molto efficiente perché (1) timemi dice che il tempo di sistema per tale copia è di soli ~ 45 secondi; e perché (2) quando esamino topdurante la copia, % CPU è piuttosto bassa (mediante ispezione, circa lo 0-10% in media).

L'uso cpper copiare lo stesso file di ~ 20 GB da una cartella sul disco locale in un'altra cartella sullo stesso disco locale richiede meno tempo - circa 9 minuti in tempo reale (~ 51 secondi nell'ora di sistema, secondo time). Quindi apparentemente il fileserver è un po 'più lento del disco locale, come previsto, ma forse non significativamente più lento. Sono sorpreso che la copia da locale a locale locale non sia più veloce di 9 minuti.

Devo copiare ~ 200 file di grandi dimensioni - ciascuno ~ 20 GB - dal file server a uno dei dischi locali. Quindi, la mia domanda è: esiste un'alternativa più veloce alla cpcopia di file di grandi dimensioni in Linux? (O ci sono delle bandiere all'interno cpche potrei usare che accelererebbero la copia?) Anche se in qualche modo potessi radere un minuto di tempo durante questa copia, ciò aiuterebbe immensamente.

Sono sicuro che l'acquisto di nuovi dischi hardware più veloci, ma non ho accesso a tali risorse. Inoltre non sono un amministratore di sistema - sono solo un utente (principiante) - quindi non ho accesso a informazioni più dettagliate sul carico che si trova sui dischi. So che mentre una dozzina di persone usano quotidianamente il fileserver, sono l'unica persona che usa questo particolare nodo / disco locale.

% CPU dovrebbe essere in esaurimento durante una copia. La CPU dice al controller del disco "prendere i dati dai settori X-Y nel buffer di memoria su Z". Quindi va e fa qualcos'altro (o dorme, se non c'è nient'altro). L'hardware 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 torna a fare qualcos'altro.

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

1. È condiviso da tutti coloro che utilizzano il file server (e possibilmente una connessione tra switch, ecc.)
2. Ciò è limitato dalla velocità con cui il file server può gestire la scrittura, tenendo presente che la larghezza di banda di I / O del disco è condivisa da tutti gli utenti.
3. Non hai specificato come stai accedendo al file server (NFS, CIFS (Samba), AFS, ecc.). Potrebbe essere necessario ottimizzare la montatura di rete, ma su qualsiasi cosa recente, i valori predefiniti sono generalmente piuttosto sani.

Per rintracciare il collo di bottiglia, iostat -kx 10sarà un comando utile. Ti mostrerà l'utilizzo sui tuoi dischi rigidi locali. Se riesci a eseguirlo sul file server, ti dirà quanto è occupato il file server.

La soluzione generale sarà quella di accelerare quel collo di bottiglia, per il quale ovviamente non hai il budget. Ma 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 di simile lzopo forse gzip --fastest.
• Se stai cambiando solo alcuni bit qua e là, e poi rispedendo il file, solo l'invio di delta sarà molto più veloce. Sfortunatamente, rsyncnon sarà di grande aiuto qui, poiché dovrà trovare il file su entrambi i lati per trovare il delta. Invece, hai bisogno di qualcosa che tenga traccia del delta mentre cambi il file ... La maggior parte degli approcci qui sono specifici dell'app. Ma è possibile che tu possa sistemare qualcosa con, ad esempio, Device Mapper (vedi il nuovissimo obiettivo dm-era ) o btrfs.
• Se stai copiando gli stessi dati su più macchine, puoi usare qualcosa come udpcast per inviarli a tutte le macchine contemporaneamente.

E, poiché noti che non sei l'amministratore di sistema, immagino che ciò significhi che hai un amministratore di sistema. O almeno qualcuno responsabile del file server e della rete. Probabilmente dovresti chiederglielo, dovrebbero avere molta più familiarità con le specifiche della tua configurazione. I tuoi amministratori di sistema dovrebbero almeno essere in grado di dirti quale velocità di trasferimento puoi ragionevolmente aspettarti.

Potrebbe essere un'alternativa più rapida e non intaserai la rete per due giorni: prendi uno o due dischi USB (USB 3 se presenti) o FireWire di grandi dimensioni, collegalo al server e copia i file su il disco. Trasporta il disco sul tuo computer locale. Copia i file sulla macchina.

La tua definizione di efficiente è al contrario. Un'implementazione più efficiente fa perdere meno tempo alla CPU. Sulla copia locale si sta calcolando una media di circa 74 MB / s di throughput (lettura + scrittura), che è circa quanto un singolo disco rigido otterrà.

Se si dispone dell'accesso diretto SSH (o SFTP) (chiedere al proprio amministratore di sistema), è possibile utilizzare scpcon la compressione ( -C):

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

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

L' cpimplementazione probabilmente non è un collo di bottiglia. Prova a osservare l'utilizzo di I / O iotopsia sul server che sul nodo del cluster. Questo ti darà un'idea di come migliorare le prestazioni.

Un altro suggerimento è quello di 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 modo peer-to-peer piuttosto che da un server a tutti i client. È un po 'più complicato da implementare, ma puoi anche provare a usare qualche riga di comando p2p come l'hub di connessione diretta.

Se all'interno di quei file 20G, alcune parti sono comuni e altre sono specifiche del nodo del cluster, considerare di dividerle in parti comuni e specifiche e quindi distribuire parte comune in modo p2p.

La natura / i contenuti di questi file possono fare qualche differenza. Ho capito che devi copiare 200 file, ~ 20 GB ciascuno, da un computer all'altro, vero?

Se quei file sono comprimibili o con pezzi simili / identici, hai due approcci:

• comprimili prima di copiarli o crea un tunnel tra i computer con abilitazione zip su di essi. Quindi, se la rete è il collo di bottiglia, sarà un po 'più veloce

• se i file sono molto simili o condividono tra loro alcuni contenuti comuni, prova a utilizzare rsync . Trascorrerà del tempo a trovare ciò che è comune tra i file e non sarà necessario copiarlo letteralmente , perché lo ricostruirà in base a ciò che è comune.

modificare

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

In tal caso, rsync sarà utile, perché tenterà di rilevare ciò che è uguale tra le versioni e non copiare ciò che è invariato.

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

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

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

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

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

Non esiste 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

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

Il comando buffer imposta due processi per eseguire contemporaneamente il processo di copia: uno per la lettura e l'altro per la scrittura e utilizza un buffer di memoria condivisa 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.

Perché non provare un algoritmo di propagazione P2P, se è necessario aggiornare l'intero cluster contemporaneamente?

https://github.com/lg/murder è ciò che utilizza Twitter

C'è anche BTSync che puoi provare.

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

git o hg possono tenere traccia e rilevare i delta e trasferirli solo. 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 rolling per rilevare i delta senza una conoscenza preliminare di cosa c'è dall'altra parte. Sebbene rsync richieda più lavoro per calcolare i delta, non è necessario archiviare l'intera cronologia dei file.

Potresti provare a impacchettare tutti i file in un unico archivio (non è necessario comprimerlo). Nella mia esperienza, copiare quell'archivio è più veloce della copia di un gran numero di singoli file

Prova bbcp . I test nel nostro ambiente hanno rivelato che cp aveva una sorta di governatore incorporato. Fai solo attenzione perché quando togli il governatore, puoi red-line il tuo server e causare un'interruzione. Nel nostro caso stavamo portando il server offline per fare la copia, quindi più veloce era meglio. Questo ha migliorato il tempo di trasferimento di diverse ore.

Assicurarsi che i file di destinazione non esistano prima della copia.

A volte è sorprendente quanto tempo viene impiegato anche solo copiando sullo stesso host (nessuna rete coinvolta).

Vedi la mia risposta a un'altra domanda cp qui . Per farla breve, sovrascrivere un file esistente è molto più lento che troncarlo o scollegarlo prima, quindi copiarlo. Quest'ultimo è 8 volte più veloce per un file da 1,2 GB.