Qual è il modo più veloce per inviare enormi quantità di dati tra due computer? [chiuso]

Questa è una situazione in cui mi trovo spesso:

• Ho un server di origine con un disco rigido da 320 GB al suo interno e 16 GB di RAM ( specifiche esatte disponibili qui , ma poiché questo è un problema che incontro spesso anche su altre macchine, preferirei che la risposta funzionasse su qualsiasi macchina Linux "ragionevole")
• Ho un server di backup con diversi terabyte di spazio sul disco rigido ( qui le specifiche esatte , vedere la dichiarazione di non responsabilità sopra)

Voglio trasferire 320 GB di dati dal server di origine al server di destinazione (in particolare, i dati da /dev/sda).

1. I due computer sono fisicamente uno accanto all'altro, quindi posso far passare i cavi tra di loro.
2. Sono su una LAN e sto usando un nuovo router , il che significa che la velocità della mia rete dovrebbe "idealmente" essere 1000Mbit, giusto?
3. La sicurezza non è un problema. Sono su una rete locale e mi fido di tutte le macchine della rete, incluso il router.
4. (facoltativo) Non ho necessariamente bisogno di un checksum firmato dei dati, ma il controllo degli errori di base (come i pacchetti rilasciati o l'unità che diventa illeggibile) dovrebbe essere rilevato piuttosto che scomparire nell'output.

Ho cercato questa domanda online e ho testato diversi comandi. Quello che appare più spesso è questo:

ssh user@192.168.1.100 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz

Questo comando si è rivelato troppo lento (ha funzionato per un'ora, ha ottenuto solo circa 80 GB attraverso i dati). Sono stati necessari circa 1 minuto e 22 secondi per il pacchetto di test da 1 GB e alla fine sono stati due volte più veloci quando non sono compressi. I risultati potrebbero anche essere stati distorti dal fatto che il file trasferito è inferiore alla quantità di RAM sul sistema di origine.

Inoltre (e questo è stato testato su provini da 1 GB), ottengo problemi se uso il gzipcomando e dd; il file risultante ha un checksum diverso quando viene estratto sulla destinazione, rispetto a quando viene reindirizzato direttamente. Sto ancora cercando di capire perché questo sta accadendo.

Poiché i server sono fisicamente uno accanto all'altro e nei commenti hai menzionato l'accesso fisico, il modo più veloce sarebbe quello di estrarre il disco rigido dal primo computer, posizionarlo nel secondo e trasferire i file tramite la connessione SATA.

netcat è ottimo per situazioni come questa in cui la sicurezza non è un problema:

# on destination machine, create listener on port 9999
nc -l 9999 > /path/to/outfile

# on source machine, send to destination:9999
nc destination_host_or_ip 9999 < /dev/sda
# or dd if=/dev/sda | nc destination_host_or_ip 9999

Nota, se stai usando ddda GNU coreutils, puoi inviarlo SIGUSR1al processo ed esso emetterà progressi su stderr. Per BSD dd, utilizzare SIGINFO.

pv è ancora più utile nel riportare i progressi durante la copia:

# on destination
nc -l 9999 | pv > /path/to/outfile

# on source
pv /dev/sda | nc destination_host_or_ip 9999
# or dd if=/dev/sda | pv | nc destination_host_or_ip 9999

1. Non usare veloce di compressione.

   • Qualunque sia il tuo mezzo di trasferimento, specialmente per rete o usb, lavorerai con raffiche di dati per letture, cache e scritture, e queste non saranno esattamente sincronizzate.
   • Oltre al firmware del disco, alle cache del disco e alle cache del kernel / ram, se puoi anche utilizzare le CPU dei sistemi in qualche modo per concentrare la quantità di dati scambiati per burst, allora dovresti farlo .
   • Qualsiasi algoritmo di compressione gestirà automaticamente le corse sparse di input il più velocemente possibile, ma ci sono pochissimi che gestiranno il resto ai throughput di rete.
   • lz4 è la tua migliore opzione qui:

     LZ4 è un algoritmo di compressione lossless molto veloce, che fornisce una velocità di compressione di 400 MB / s per core, scalabile con CPU multi-core. Dispone inoltre di un decodificatore estremamente veloce, con velocità in più GB / s per core, che in genere raggiunge i limiti di velocità RAM sui sistemi multi-core.

2. Preferibilmente non cercare inutilmente.

   • Questo può essere difficile da valutare.

   • Se c'è molto spazio libero sul dispositivo da cui copi e il dispositivo non è stato azzerato di recente, ma tutti i file system di origine devono essere copiati, probabilmente vale la pena fare prima qualcosa di simile a:

     </dev/zero tee >empty empty1 empty2; sync; rm empty*

   • Ma dipende da quale livello dovresti leggere la fonte. Di solito è desiderabile leggere il dispositivo dall'inizio alla fine dal suo /dev/some_diskfile di dispositivo, poiché la lettura a livello di file system generalmente implica la ricerca avanti e indietro e intorno al disco in modo non sequenziale. E quindi il tuo comando read dovrebbe essere qualcosa del tipo:

     </dev/source_device lz4 | ...

   • Tuttavia, se il tuo file system di origine non deve essere trasferito per intero, la lettura a livello di file system è praticamente inevitabile, e quindi dovresti raggruppare i contenuti di input in uno stream. paxè generalmente la soluzione migliore e più semplice in quel caso, ma potresti anche prendere mksquashfsin considerazione .

     pax -r /source/tree[12] | lz4 | ...
     mksquashfs /source/tree[12] /dev/fd/1 -comp lz4 | ...

3. Non Non cifrare con ssh.

   • L'aggiunta dell'overhead di crittografia a un supporto affidabile non è necessaria e può essere gravemente dannosa per la velocità dei trasferimenti sostenuti in quanto i dati letti devono essere letti due volte .
   • Il PRNG ha bisogno dei dati letti, o almeno di alcuni di essi, per sostenere la casualità.
   • E ovviamente è necessario trasferire anche i dati.
   • È inoltre necessario trasferire l'overhead di crittografia stesso, il che significa più lavoro per meno dati trasferiti per raffica .

   • E quindi piuttosto dovresti usare netcat( o, come preferisco, il nmapprogetto è più capacencat ) per una semplice copia di rete, come è stato suggerito altrove:

     ###  on tgt machine...
     nc -l 9999 > out.lz4
     ###  then on src machine...
     ... lz4 | nc tgt.local 9999

Esistono diverse limitazioni che potrebbero limitare la velocità di trasferimento.

1. Esiste un sovraccarico di rete intrinseco su una pipe da 1 Gbps. In genere, ciò riduce la velocità effettiva a 900 Mbps o meno. Quindi devi ricordare che si tratta di traffico bidirezionale e dovresti aspettarti un calo significativamente inferiore a 900 Mbps.

2. Anche se stai usando un "nuovo router" sei sicuro che il router supporti 1 Gbps? Non tutti i nuovi router supportano 1 Gbps. Inoltre, a meno che non si tratti di un router di livello aziendale, è probabile che si verifichi una perdita di larghezza di banda aggiuntiva per il router che risulta inefficiente. Sebbene basato su quello che ho trovato di seguito, sembra che tu stia superando i 100 Mbps.

3. Potrebbe esserci congestione della rete da altri dispositivi che condividono la tua rete. Hai provato a utilizzare un cavo collegato direttamente come hai detto di essere in grado di fare?

4. Quale quantità di I / O del disco stai usando? Probabilmente, non sei limitato dalla rete, ma dall'unità disco. La maggior parte degli HDD a 7200 giri / min raggiunge solo i 40 MB / s. Stai usando il raid? Stai usando SSD? Cosa stai usando sull'estremità remota?

Suggerisco di utilizzare rsync se si prevede che questo verrà rieseguito per i backup. Puoi anche scp, ftp (s) o http usando un downloader come filezilla dall'altra parte in quanto parallelizzerà le connessioni ssh / http / https / ftp. Ciò può aumentare la larghezza di banda in quanto le altre soluzioni sono su un singolo tubo. Un singolo pipe / thread è ancora limitato dal fatto che è single thread, il che significa che potrebbe anche essere associato alla CPU.

Con rsync, elimini gran parte della complessità della tua soluzione, oltre a consentire la compressione, la conservazione delle autorizzazioni e i trasferimenti parziali. Esistono molte altre ragioni, ma è generalmente il metodo di backup preferito (o esegue i sistemi di backup) delle grandi aziende. Commvault utilizza effettivamente rsync sotto il loro software come meccanismo di consegna per i backup.

Sulla base del tuo esempio di 80 GB / h, ottieni circa 177 Mbps (22,2 MB / s). Sento che potresti facilmente raddoppiare questo con rsync su una linea ethernet dedicata tra le due caselle poiché sono riuscito a ottenere questo nei miei test con rsync su gigabit.

Ci occupiamo di questo regolarmente.

I due metodi principali che tendiamo a usare sono:

1. SATA / eSATA / sneakernet
2. Montaggio diretto NFS, quindi locale cporsync

Il primo dipende dal fatto che l'unità possa essere trasferita fisicamente. Questo non è sempre il caso.

Il secondo funziona sorprendentemente bene. Generalmente, con un supporto NFS diretto, massimizziamo piuttosto facilmente una connessione da 1 gbps. Non ti avvicinerai a nulla con scp, dd over ssh o qualcosa di simile (otterrai spesso una frequenza massima sospettosamente vicina a 100mpbs). Anche su processori multicore molto veloci colpirai un collo di bottiglia sul throughput massimo di criptovaluta di uno dei core sulla più lenta delle due macchine, che è deprimentemente lento rispetto al cp o rsync a passaggio pieno su un mount di rete non crittografato. Occasionalmente colpirai un muro di iops per un po 'e rimarrai bloccato a circa ~ 53 MB / s invece dei più tipici ~ 110 MB / s, ma di solito è di breve durata a meno che la fonte o la destinazione non siano effettivamenteuna singola unità, quindi potresti finire per essere limitato dalla velocità sostenuta dell'unità stessa (che varia abbastanza per ragioni casuali che non conoscerai fino a quando non la proverai effettivamente) - meh.

NFS può essere un po 'fastidioso da installare se si trova su una distribuzione sconosciuta, ma in generale è stato il modo più veloce per riempire i tubi nel modo più completo possibile. L'ultima volta che l'ho fatto su 10 gbps non ho mai scoperto se ha raggiunto il limite massimo della connessione, perché il trasferimento era terminato prima che tornassi dall'afferrare un caffè - quindi potrebbe esserci un limite naturale che hai colpito lì. Se si dispone di alcuni dispositivi di rete tra l'origine e la destinazione, è possibile riscontrare alcuni lievi ritardi o singhiozzi dall'effetto viscoso della rete, ma in genere questo funzionerà in tutto l'ufficio (senza altro traffico che lo confonde) o da un'estremità del datacenter a l'altro (a meno che tu non abbia una sorta di filtro / ispezione che si verificano internamente, nel qual caso tutte le scommesse sono disattivate ).

MODIFICARE

Ho notato delle chiacchiere sulla compressione ... non comprimere la connessione. Ti rallenterà allo stesso modo di un livello crittografico. Il collo di bottiglia sarà sempre un singolo core se comprimerai la connessione (e non otterrai nemmeno un utilizzo particolarmente buono del bus di quel core). La cosa più lenta che puoi fare nella tua situazione è usare un canale crittografato e compresso tra due computer seduti uno accanto all'altro su una connessione da 1 gbps o superiore.

PROVA DI FUTURO

Questo consiglio è valido per metà 2015. Questo non sarà quasi certamente il caso per troppi anni. Quindi prendi tutto con un pizzico di sale e, se affronti regolarmente questo compito, prova una varietà di metodi su carichi effettivi invece di immaginare che otterrai qualcosa di simile agli ottimum teorici, o addirittura osserverai le velocità di compressione / crittografia tipiche di cose come il web il traffico, in gran parte testuale (protip: i trasferimenti di massa di solito consistono principalmente in immagini, audio, video, file di database, codice binario, formati di file di Office, ecc. che sono già compressia modo loro e traggono ben poco beneficio dall'esecuzione di un'altra routine di compressione, la cui dimensione del blocco di compressione è quasi garantita per non allinearsi con i dati binari già compressi ...).

Immagino che in futuro concetti come SCTP saranno portati in un posto più interessante, dove le connessioni bonded (o le connessioni in fibra canalizzate internamente dallo spettro) sono tipiche e ogni canale può ricevere un flusso indipendente dagli altri, e ciascuno il flusso può essere compresso / crittografato in parallelo, ecc. ecc. Sarebbe meraviglioso! Ma non è così oggi nel 2015, e sebbene fantasticare e teorizzare sia bello, la maggior parte di noi non ha cluster di archiviazione personalizzati in esecuzione in una camera criogenica che alimentano i dati direttamente all'interno di un Blue Gene / Q che genera risposte per Watson. Questa non è la realtà. Né abbiamo il tempo di analizzare esaurientemente il nostro payload di dati per capire se la compressione è una buona idea o meno - il trasferimento stesso sarebbe finito prima di aver finito la nostra analisi,

Ma...

I tempi cambiano e la mia raccomandazione contro la compressione e la crittografia non regge. Mi piacerebbe molto che questo consiglio venisse rovesciato molto presto nel caso tipico . Mi renderebbe la vita più semplice.

Uno strumento elegante che ho usato in passato è bbcp. Come visto qui: https://www.slac.stanford.edu/~abh/bbcp/ .

Vedi anche http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm

Ho avuto velocità di trasferimento molto elevate con questo strumento.

Se in qualche modo ricevi un primo passaggio (via cavo / sneakernet / qualunque cosa), puoi esaminare rsyncalcune opzioni che possono velocizzare notevolmente i trasferimenti successivi. Un ottimo modo per andare sarebbe:

rsync -varzP sourceFiles destination

Le opzioni sono: verbose, modalità archivio, ricorsive, compress, avanzamento parziale

Aggiunto su insistenza del poster originale nei commenti alla risposta di zackse, anche se non sono sicuro che sia il più veloce in circostanze tipiche.

bashha una speciale sintassi reindirizzamento:
Per uscita:      > /dev/tcp/ IP  / port
Per l'ingresso:       < /dev/tcp/ IP  / porta
IP ban essere o IP punteggiato decimale o un nome host; il divieto di porta può essere un numero decimale o un nome di porta da /etc/services.

Non esiste una /dev/tcp/directory effettiva . È un kludge sintattico speciale che comanda bashdi creare un socket TCP, collegarlo alla destinazione specificata e quindi fare la stessa cosa di un normale reindirizzamento dei file (vale a dire, sostituire il rispettivo flusso standard con il socket usando dup2 (2)).

Pertanto, è possibile eseguire lo streaming dei dati da ddo tarverso la macchina di origine direttamente tramite TCP. O, al contrario, per lo streaming di dati taro qualcosa di simile direttamente tramite TCP. In ogni caso, viene eliminato un netcat superfluo.

Note su netcat

Esiste un'incoerenza nella sintassi tra netcat classico e netcat GNU . Userò la sintassi classica a cui sono abituato. Sostituire -lpcon -lper GNU Netcat.

Inoltre, non sono sicuro che GNU Netcat accetti lo -qswitch.

Trasferimento di un'immagine del disco

(Sulla falsariga della risposta di zackse.)
Sulla destinazione:

nc -lp 9999 >disk_image

Sulla fonte:

dd if=/dev/sda >/dev/tcp/destination/9999
 

Creazione di un archivio tar.gz, con tar

A destinazione:

nc -lp 9999 >backup.tgz

Sulla fonte:

tar cz files or directories to be transferred >/dev/tcp/destination/9999

Sostituisci .tgzcon .tbze czcon cjper ottenere un bzip2archivio compresso.

Trasferimento con espansione immediata nel file system

Anche con tar.
A destinazione:

cd backups
tar x </dev/tcp/destination/9999

Sulla fonte:

tar c files or directories to be transferred |nc -q 1 -lp 9999

-q 1Funzionerà senza , ma netcat si bloccherà al termine dei dati. Vedi tar (1) per la spiegazione della sintassi e avvertenze di tar. Se ci sono molti file con ridondanza elevata (bassa entropia), è possibile provare la compressione (ad es. czE xzinvece di ce x), ma se i file sono tipici e la rete è abbastanza veloce, rallenterebbe il processo. Vedi la risposta di mikeserv per i dettagli sulla compressione.

Stile alternativo (la destinazione ascolta la porta)

A destinazione:

cd backups
nc -lp 9999 |tar x

Sulla fonte:

tar c files or directories to be transferred >/dev/tcp/destination/9999

Prova i suggerimenti relativi alle connessioni dirette ed evitando protocolli crittografati come ssh. Quindi, se vuoi ancora migliorare ogni singola prestazione, dai a questo sito una lettura: https://fasterdata.es.net/host-tuning/linux/ per alcuni consigli su come ottimizzare le tue finestre TCP.

Vorrei usare questo script che ho scritto che necessita del socatpacchetto.

Sulla macchina di origine:

tarnet -d wherefilesaretosend pass=none 12345 .

Sulla macchina target:

tarnet -d wherefilesaretogo pass=none sourceip/12345

Se il vbufpacchetto (Debian, Ubuntu) è lì, il mittente del file mostrerà un progresso dei dati. Il ricevitore di file mostrerà quali file sono stati ricevuti. L'opzione pass = può essere utilizzata laddove i dati potrebbero essere esposti (più lentamente).

Modificare:

Utilizzare l' -nopzione per disabilitare la compressione, se la CPU è un collo di bottiglia.

Se il budget non è la preoccupazione principale, puoi provare a connettere le unità con un "connettore unità" Intel Xeon E5 12 core. Questo connettore di solito è così potente che puoi persino eseguire il tuo attuale software server su di esso. Da entrambi i server!

Questa potrebbe sembrare una risposta divertente, ma dovresti davvero considerare il motivo per cui stai spostando i dati tra i server e se uno di grandi dimensioni con memoria e archiviazione condivise potrebbe avere più senso.

Non sei sicuro delle specifiche attuali, ma il trasferimento lento potrebbe essere limitato dalle velocità del disco, non dalla rete?

Se ti preoccupi solo dei backup e non di un byte per la copia byte del disco rigido, allora consiglierei backupPC. http://backuppc.sourceforge.net/faq/BackupPC.html È un po 'una seccatura da configurare ma si trasferisce molto rapidamente.

Il mio tempo di trasferimento iniziale per circa 500 G di dati era di circa 3 ore. I backup successivi avvengono in circa 20 secondi.

Se non sei interessato ai backup, ma stai cercando di sincronizzare le cose, rsync o all'unisono si adatteranno meglio alle tue esigenze.

Un byte per la copia byte di un disco rigido è in genere un'idea orribile a fini di backup (nessun incremento, nessun risparmio di spazio, l'unità non può essere utilizzata, è necessario eseguire il backup dello "spazio vuoto" e eseguire il backup della spazzatura (come un file di scambio 16 G o 200 G di core dump o alcuni di questi). Usando rsync (o backuppc o altri) puoi creare "istantanee" in tempo così puoi andare a "come appariva il tuo file system 30 minuti fa" con spese generali molto ridotte.

Detto questo, se vuoi davvero trasferire un byte per la copia dei byte, il tuo problema risiederà nel trasferimento e non nel recupero dei dati dall'unità. Senza 400 G di RAM, un trasferimento di file da 320 G impiegherà molto tempo. L'uso di protocolli non crittografati è un'opzione, ma in ogni caso, dovrai semplicemente sederti lì e aspettare diverse ore (sulla rete).

Indipendentemente dal programma, di solito ho scoperto che "tirare" i file su una rete è più veloce di "spingere". Cioè, accedere al computer di destinazione e fare una lettura è più veloce che accedere al computer di origine e fare una scrittura.

Inoltre, se si intende utilizzare un'unità intermedia, considerare quanto segue: Procurarsi un'unità esterna (come pacchetto o un'unità separata collegata a una docking station) che utilizza eSATA anziché USB. Quindi su ciascuno dei due computer installare una scheda con una porta eSATA o ottenere un semplice cavo adattatore che porta una delle porte SATA interne a un connettore eSATA esterno. Quindi collega l'unità al computer di origine, accendi l'unità e attendi che si monti automaticamente (potresti montare manualmente, ma se lo fai ripetutamente potresti anche metterlo nel tuo file fstab). Quindi copia; scriverai alla stessa velocità di un disco interno. Quindi smontare l'unità, spegnere, collegare all'altro computer, accendere, attendere un montaggio automatico e leggere.

Consiglio di dare un'occhiata al team di NIC. Ciò comporta l'utilizzo di più connessioni di rete in esecuzione in parallelo. Supponendo che tu abbia davvero bisogno di un trasferimento superiore a 1 GB e che 10 GB siano proibitivi in ​​termini di costi, i 2 GB forniti dal team di NIC rappresenterebbero un costo minore e che i tuoi computer potrebbero già disporre di porte extra.

FWIW, l'ho sempre usato:

tar -cpf - <source path> | ssh user@destserver "cd /; tar xf -"

La cosa su questo metodo è che manterrà le autorizzazioni di file / cartelle tra le macchine (supponendo che esistano gli stessi utenti / gruppi su entrambi) (Inoltre, in genere lo faccio per copiare le immagini del disco virtuale poiché posso usare un parametro -S per gestire i file sparsi. )

Ho appena provato questo tra due server occupati e gestito ~ 14 GB in 216s (circa 64 MB / s) - potrebbe fare di meglio tra macchine dedicate e / o compressione ... YMMV

$ date; tar -cpf - Installers | ssh elvis "cd /home/elvis/tst; tar xf -"; date
Wed Sep  9 15:23:37 EDT 2015
Wed Sep  9 15:27:13 EDT 2015

$ du -s Installers
14211072   Installers

A meno che tu non voglia fare analisi forensi del filesystem, usa un programma di dump / restore per il tuo filesystem per evitare di copiare lo spazio libero che FS non sta usando. A seconda del file system che hai, questo in genere preserverà tutti i metadati, incluso ctime. i numeri di inode possono cambiare, comunque, a seconda del filesystem (xfs, ext4, ufs ...).

La destinazione del ripristino può essere un file sul sistema di destinazione.

Se vuoi un'immagine a tutto disco con la tabella delle partizioni, puoi ottenere ddi primi 1M del disco per ottenere la tabella delle partizioni / bootloader / roba, ma poi xfsdumple partizioni.

Non posso dire dal tuo dump di informazioni che tipo di filesystem hai effettivamente. Se si tratta di BSD ufs, penso che abbia un programma di dump / ripristino. Se è ZFS, bene IDK, potrebbe esserci qualcosa.

Generalmente la copia completa dei dischi è troppo lenta per tutto tranne che per le situazioni di ripristino. Non è nemmeno possibile eseguire backup incrementali in questo modo.

È inoltre possibile configurare i sistemi per avere uno spazio di archiviazione condiviso!

Sto considerando che questi sono uno accanto all'altro e probabilmente lo farai ancora e ancora ....

Che ne dici di un cavo crossover Ethernet? Invece di affidarti alle velocità wireless sei limitato alla velocità cablata della tua scheda di rete.

Ecco una domanda simile con alcuni esempi di quel tipo di soluzione.

Apparentemente al giorno d'oggi basterà solo un tipico cavo Ethernet. Ovviamente migliore è la tua scheda di rete, più veloce è il trasferimento.

Per riassumere, se è necessaria una configurazione di rete, dovrebbe essere limitata alla semplice impostazione di IP statici per il server e il computer di backup con una subnet mask 255.255.255.0

In bocca al lupo!

Modificare:

@Khrystoph ha toccato questo nella sua risposta

Molte persone raccomandano di saltare ssh perché la crittografia ti rallenterà. Le moderne CPU possono effettivamente essere abbastanza veloci a 1Gb, ma OpenSSH ha problemi con l'implementazione di finestre interne che possono rallentare drasticamente.

Se vuoi farlo con ssh, dai un'occhiata a HPN SSH . Risolve i problemi di finestre e aggiunge la crittografia multithread. Sfortunatamente dovrai ricostruire ssh sia sul client che sul server.

OK Ho tentato di rispondere a questa domanda per due computer con "pipe molto grandi" (10Gbe) che sono "vicine" tra loro.

Il problema che si presenta qui è: la maggior parte della compressione si strozzerà nella CPU, poiché i tubi sono così grandi.

prestazioni per il trasferimento di file da 10 GB (connessione di rete 6 Gb [linode], dati non comprimibili):

$  time bbcp 10G root@$dest_ip:/dev/null
0m16.5s 

iperf:

server: $ iperf3 -s -F /dev/null
client:
$ time iperf3 -c $dest_ip -F 10G -t 20 # -t needs to be greater than time to transfer complete file
0m13.44s
(30% cpu)

netcat (1.187 openbsd):

server: $ nc -l 1234 > /dev/null
client: $ time nc $dest_ip 1234 -q 0 < 10G 
0m13.311s
(58% cpu)

scp:

$ time /usr/local/bin/scp 10G root@$dest_ip:/dev/null
1m31.616s
scp with hpn ssh patch (scp -- hpn patch on client only, so not a good test possibly): 
1m32.707s

socat:

server:
$ socat -u TCP-LISTEN:9876,reuseaddr OPEN:/dev/null,creat,trunc
client:
$ time socat -u FILE:10G TCP:$dest_ip:9876
0m15.989s

E due scatole su 10 Gbe, versioni leggermente più vecchie di netcat (CentOs 6.7), file da 10 GB:

nc: 0m18.706s (100% cpu, v1.84, no -q option
iperf3: 0m10.013s (100% cpu, but can go up to at least 20Gbe with 100% cpu so not sure it matters)
socat: 0m10.293s (88% cpu, possibly maxed out)

Quindi in un caso netcat ha usato meno CPU, dall'altro socat, quindi YMMV.

Con netcat, se non ha un'opzione "-N -q 0" può trasferire file troncati, fai attenzione ... altre opzioni come "-w 10" possono anche causare file troncati.

Ciò che sta accadendo in quasi tutti questi casi è che la CPU è al massimo, non la rete. scpraggiunge un massimo di circa 230 MB / s, ancorando un core al 100% di utilizzo.

Sfortunatamente Iperf3 crea file corrotti . Alcune versioni di netcat sembrano non trasferire l'intero file, molto strano. Soprattutto le versioni precedenti di esso.

Vari incantesimi di "gzip come pipe per netcat" o "mbuffer" sembravano anche massimizzare la cpu con gzip o mbuffer, quindi non ha comportato un trasferimento più veloce con tubi così grandi. lz4 potrebbe aiutare. Inoltre, alcune delle cose del tubo gzip che ho tentato hanno portato a trasferimenti corrotti per file molto grandi (> 4 GB), quindi fai attenzione :)

Un'altra cosa che potrebbe funzionare soprattutto per una latenza più elevata (?) È ottimizzare le impostazioni di tcp. Ecco una guida che menziona i valori suggeriti:

http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm e https://fasterdata.es.net/host-tuning/linux/ (da un'altra risposta) possibilmente impostazioni IRQ: https://fasterdata.es .net / host-tuning / 100g-tuning /

suggerimenti da linode, aggiungere a /etc/sysctl.conf:

net.core.rmem_max = 268435456 
net.core.wmem_max = 268435456 
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_no_metrics_save = 1
net.core.default_qdisc = fq 

Inoltre, vorrebbero che tu eseguissi:

 /sbin/ifconfig eth0 txqueuelen 10000 

vale la pena ricontrollare dopo aver modificato per assicurarsi che le modifiche non causino danni.

Potrebbe anche valere la pena regolare la dimensione della finestra: https://iperf.fr/iperf-doc.php#tuningtcp

Con connessioni lente (er) la compressione può sicuramente aiutare però. Se hai pipe di grandi dimensioni, una compressione molto veloce potrebbe aiutare con dati facilmente comprimibili, non l'ho mai provato.

La risposta standard per "sincronizzare i dischi rigidi" è risincronizzare i file, evitando il trasferimento ove possibile.

Un'altra opzione: usa "parallel scp" (in qualche modo o altro), quindi utilizzerà più core ...