Perché rsync è più veloce di NFS?

Pochi giorni fa ho notato qualcosa di piuttosto strano (almeno per me). Ho eseguito rsync copiando gli stessi dati ed eliminandoli successivamente sul mount NFS, chiamato /nfs_mount/TEST. Questo /nfs_mount/TESTè ospitato / esportato da nfs_server-eth1. L'MTU su entrambe le interfacce di rete è 9000, il passaggio tra supporta anche i jumbo frame. Se lo faccio rsync -av dir /nfs_mount/TEST/ottengo velocità di trasferimento in rete X MBps. Se lo faccio rsync -av dir nfs_server-eth1:/nfs_mount/TEST/ottengo una velocità di trasferimento in rete di almeno 2X MBps. Le mie opzioni di montaggio NFS sono nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp.

In conclusione: entrambi i trasferimenti passano sulla stessa sottorete di rete, stessi cavi, stesse interfacce, leggono gli stessi dati, scrivono nella stessa directory, ecc. L'unica differenza è tramite NFSv3, l'altra su rsync.

Il client è Ubuntu 10.04, il server Ubuntu 9.10.

Come mai rsync è molto più veloce? Come far corrispondere NFS a quella velocità?

Grazie

Modifica: nota che uso rsync per scrivere sulla condivisione NFS o su SSH nel server NFS e scrivere localmente lì. Entrambe le volte lo faccio rsync -av, a partire dalla directory di destinazione chiara. Domani proverò con una copia semplice.

Modifica2 (informazioni aggiuntive): la dimensione del file varia da 1 KB a 15 MB. I file sono già compressi, ho provato a comprimerli ulteriormente senza successo. Ho fatto il tar.gzfile da quello dir. Ecco lo schema:

• rsync -av dir /nfs_mount/TEST/ = trasferimento più lento;
• rsync -av dir nfs_server-eth1:/nfs_mount/TEST/= rsync più veloce con jumbo frame abilitato; senza jumbo frame è un po 'più lento, ma comunque significativamente più veloce di quello direttamente a NFS;
• rsync -av dir.tar.gz nfs_server-eth1:/nfs_mount/TEST/ = circa uguale al suo equivalente non tar.gz;

Test con cpe scp:

• cp -r dir /nfs_mount/TEST/= leggermente più veloce di rsync -av dir /nfs_mount/TEST/ma ancora significativamente più lento di rsync -av dir nfs_server-eth1:/nfs_mount/TEST/.
• scp -r dir /nfs_mount/TEST/= più veloce nel complesso, leggermente superato rsync -av dir nfs_server-eth1:/nfs_mount/TEST/;
• scp -r dir.tar.gz /nfs_mount/TEST/ = circa uguale al suo equivalente non tar.gz;

Conclusione, basata su questi risultati: per questo test non vi è alcuna differenza significativa se si utilizza il file tar.gz di grandi dimensioni o molti di quelli piccoli. Anche i frame jumbo attivati ​​o disattivati ​​non fanno quasi alcuna differenza. cpe scpsono più veloci dei rispettivi rsync -avequivalenti. Scrivere direttamente sulla condivisione NFS esportata è significativamente più lento (almeno 2 volte) rispetto alla scrittura nella stessa directory su SSH, indipendentemente dal metodo utilizzato.

Le differenze tra cpe rsyncnon sono rilevanti in questo caso. Ho deciso di provare cpe scpsolo per vedere se mostrano lo stesso modello e lo fanno - differenza 2X.

Mentre uso rsynco cpin entrambi i casi, non riesco a capire cosa impedisce a NFS di raggiungere la velocità di trasferimento degli stessi comandi su SSH.

Come mai la scrittura sulla condivisione NFS è 2 volte più lenta della scrittura nello stesso posto su SSH?

Edit3 (server NFS / etc / opzioni di esportazione): rw,no_root_squash,no_subtree_check,sync. Il cliente / proc / mounts spettacoli: nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp.

Grazie a tutti!

Forse non è una velocità di trasferimento più lenta, ma una maggiore latenza di scrittura. Prova a montare la condivisione NFS asincrona invece di sincronizzare e vedi se questo colma il gap di velocità. Quando rsincronizzi su ssh, il processo rsync remoto scrive in modo asincrono (rapidamente). Ma quando si scrive sulla condivisione nfs montata in modo sincrono, le scritture non vengono confermate immediatamente: il server NFS attende fino a quando non hanno colpito il disco (o più probabilmente la cache del controller) prima di inviare la conferma al client NFS che la scrittura ha avuto esito positivo.

Se 'async' risolve il tuo problema, tieni presente che se qualcosa accade al server NFS durante la scrittura, molto bene potresti finire con dati incoerenti sul disco. Finché questa montatura NFS non è la memoria principale per questi (o altri) dati, probabilmente starai bene. Ovviamente saresti nella stessa barca se avessi staccato la spina sul server nfs durante / dopo l'esecuzione di rsync-over-ssh (ad es. Rsync restituisce "finito", il server nfs si arresta in modo anomalo, i dati non memorizzati nella cache di scrittura ora sono persi lasciando dati incoerenti sul disco).

Sebbene non sia un problema con il tuo test (risincronizzazione di nuovi dati), tieni presente che rsync su ssh può fare richieste significative di CPU e I / O sul server remoto prima che venga trasferito un singolo byte mentre calcola i checksum e genera l'elenco di file che devono essere aggiornato.

NFS è un protocollo di condivisione, mentre Rsync è ottimizzato per i trasferimenti di file; ci sono molte ottimizzazioni che possono essere fatte quando conosci a priori che il tuo obiettivo è quello di copiare i file il più velocemente possibile invece di fornire loro un accesso condiviso.

Questo dovrebbe aiutare: http://en.wikipedia.org/wiki/Rsync

Rsync è un protocollo di file che trasferisce solo i bit modificati tra i file. NFS è un protocollo di file di directory remoto che gestisce tutto ogni volta ... un po 'come un SMB in un certo senso. I due sono diversi e per scopi diversi. È possibile utilizzare Rsync per trasferire tra due condivisioni NFS.

Questo è interessante. Una possibilità che potresti non aver considerato è il contenuto / tipo di file che stai trasmettendo.

Se hai scadenze di piccoli file (ad es. E-mail in singoli file), l'efficienza di NFS potrebbe aumentare a causa del mancato utilizzo dell'intero MTU (forse questo è meno probabile con TCP su UDP).

In alternativa, se si dispone di file / dati altamente comprimibili, CPU veloci e una rete che non ha abbastanza la velocità della CPU (*), è possibile ottenere la velocità solo dalla compressione implicita sul collegamento ssh.

Una terza possibilità è che i file (o una loro versione) esistano già nella destinazione. In questo caso lo speedup sarebbe dovuto al fatto che il protocollo rsync ti salva trasferendo i file.

(*) In questo caso per "velocità", mi riferisco alla velocità con cui la CPU può comprimere i dati rispetto alla velocità con cui la rete può trasmettere i dati, ad esempio ci vogliono 5 secondi per inviare 5 MB attraverso il filo, ma la CPU può comprimere quei 5 MB in 1 MB in 1 secondo. In questo caso il tempo di trasmissione dei dati compressi sarebbe leggermente superiore a 1 secondo, mentre i dati non compressi sono 5 secondi.

Uso anche -e "ssh Ciphers = arcfour" per aumentare il throughput.

se il tuo obiettivo è semplicemente copiare tutti i file da una posizione all'altra, tar / netcat sarà l'opzione più veloce. se sai che hai molti spazi bianchi nei tuoi file (zeri), usa l'opzione -i.

FONTE: tar cvif - / path / to / source | nc DESTINAZIONE PORTNUM DESTINAZIONE: cd / path / to / source && nc -l PORTNUM | tar xvif -

se sai che i tuoi dati sono comprimibili, usa la compressione sui tuoi comandi tar -z -j -Ipixz

Sono un fan di pixz .. parallel xz, offre un'ottima compressione e posso sintonizzare il numero di CPU che ho sulla larghezza di banda della rete. se ho una larghezza di banda più lenta userò una compressione più alta, quindi sto aspettando su CPU più della rete .. se ho una rete veloce userò una compressione molto bassa:

FONTE: tar cvif - / path / to / source | pixz -2 -p12 | nc DESTINATION PORTNUM # tar, ignora zeri, compressione pixz livello 2 usando 12 core cpu DESTINAZIONE: nc -l PORTNUM | tar -Ipixz -xvif

se ottimizzi il livello di compressione e i core, a seconda del tuo set di dati, dovresti essere in grado di mantenere la rete vicina alla saturazione e fare una compressione sufficiente il collo di bottiglia diventa il disco (di solito il lato di scrittura se i sistemi di disco di lettura e scrittura sono lo stesso).

per quanto riguarda rsync, credo che salti gli zeri in modo simile al modo in cui tar fa con quell'opzione, quindi sta trasmettendo meno dati di NFS. NFS non può fare ipotesi sui dati, quindi deve trasmettere ogni byte insieme al sovraccarico del protocollo NFS. rsync ha un certo sovraccarico ..

netcat non ha praticamente nessuno ... invierà pacchetti TCP completi che contengono nient'altro che dati a cui tieni.

con netcat, come con scp, devi inviare tutti i dati di origine in ogni momento, non puoi essere selettivo come con rsync, quindi non è adatto per backup incrementali o cose del genere, ma è buono per copiare dati o archiviare.

Hai configurato il blocco dei file su nfsshare? Potresti ottenere molte più preformance se fosse disabilitato.

Suppongo che l'aumento della velocità sia almeno in parte dovuto a "rsync src host: / path" che genera un processo locale sul computer remoto per l'invio / la ricezione, tagliando in modo efficace l'I / O a metà.