Perché il mio rsync è così lento?

Il mio laptop e la mia workstation sono entrambi collegati a uno switch Gigabit. Entrambi eseguono Linux. Ma quando copio i file con rsync, funziona male.

Ottengo circa 22 MB / s. Non dovrei teoricamente ottenere circa 125 MB / s? Qual è il fattore limitante qui?

EDIT: ho condotto alcuni esperimenti.

Scrivi le prestazioni sul laptop

Il laptop ha un filesystem xfs con crittografia completa del disco. Utilizza la aes-cbc-essiv:sha256modalità di cifratura con una lunghezza della chiave di 256 bit. Le prestazioni di scrittura su disco sono 58,8 MB / s .

iblue@nerdpol:~$ LANG=C dd if=/dev/zero of=test.img bs=1M count=1024
1073741824 Bytes (1.1 GB) copied, 18.2735 s, 58.8 MB/s

Leggi le prestazioni sulla workstation

I file che ho copiato sono su un software RAID-5 su 5 HDD. In cima al raid c'è un lvm. Il volume stesso è crittografato con lo stesso codice. La workstation ha una CPU FX-8150 con un set di istruzioni AES-NI nativo che accelera la crittografia. Le prestazioni di lettura del disco sono 256 MB / s (la cache era fredda).

iblue@raven:/mnt/bytemachine/imgs$ dd if=backup-1333796266.tar.bz2 of=/dev/null bs=1M
10213172008 bytes (10 GB) copied, 39.8882 s, 256 MB/s

Prestazioni di rete

Ho corso iperf tra i due clienti. Le prestazioni di rete sono 939 Mbit / s

iblue@raven $ iperf -c 94.135.XXX
------------------------------------------------------------
Client connecting to 94.135.XXX, TCP port 5001
TCP window size: 23.2 KByte (default)
------------------------------------------------------------
[  3] local 94.135.XXX port 59385 connected with 94.135.YYY port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.09 GBytes   939 Mbits/sec

Un altro modo per mitigare un elevato utilizzo della CPU, ma mantenendo comunque la funzionalità di rsync, è passare da rsync / SSH a rsync / NFS. È possibile esportare i percorsi da cui si desidera copiare tramite NFS e quindi utilizzare rsync localmente dal montaggio NFS nella posizione di destinazione.

In un test da un disco di rete WD MyBook Live, uno o più rsync dal NAS su una rete Gigabit verso 2 dischi USB locali non coperebbero più di 10 MB / sec (CPU: 80% usr, 20% sys), dopo l'esportazione su NFS e rsyncing localmente dalla condivisione NFS su entrambi i dischi Ho ottenuto un totale di 45 MB / sec (al massimo entrambi i dischi USB2) e un ridotto utilizzo della CPU. L'utilizzo del disco quando si utilizza rsync / SSH era di circa il 6% e l'utilizzo di rsync / NFS era più vicino al 24%, mentre entrambi i dischi USB2 erano vicini al 100%.

Quindi abbiamo spostato efficacemente il collo di bottiglia dalla CPU NAS a entrambi i dischi USB2.

I motivi possono includere: compressione, crittografia, numero e dimensioni dei file da copiare, capacità di I / O del disco dei sistemi di origine e destinazione, sovraccarico TCP ... Questi sono tutti fattori che possono influenzare il tipo di trasferimento che stai effettuando.

Si prega di inviare il comando rsync che si sta utilizzando e fornire dettagli sulle specifiche di entrambi i computer.

Modifica: la crittografia è spesso un fattore limitante nelle velocità di sincronizzazione. Puoi eseguire con ssh e un codice di crittografia più leggero comearcfour

Qualcosa di simile a: rsync -e "ssh -c arcfour"

Oppure puoi usare un rsync / ssh modificato che può disabilitare la crittografia. Vedi hpn-ssh: http://psc.edu/networking/projects/hpn-ssh

Ma ancora una volta, il tuo laptop ha un disco lento rispetto alla tua workstation. Le scritture potrebbero essere bloccate e in attesa che l'I / O vada sul tuo laptop. Quali sono le tue aspettative prestazionali reali?

Dopo alcuni altri test, ho finalmente trovato la risposta da solo. rsyncutilizza il tunneling su ssh per impostazione predefinita. La crittografia lo rallenta. Quindi avevo bisogno di aggirare quella roba crittografica.

Soluzione 1: impostazione di un server rsync

Per usarlo tramite il rsyncprotocollo, devi configurare un server rsyncd. Sul /etc/init.d/rsyncmio laptop c'era una sceneggiatura, quindi immaginavo che rsyncd fosse in esecuzione. Mi sbagliavo. /etc/init.d/rsync startesiste silenziosamente, quando rsync non è abilitato in /etc/default/rsync. Quindi devi anche configurarlo in /etc/rsyncd.conf, il che è un dolore.

Se hai fatto tutto questo, devi usare rsync file.foo user@machine::directory. Si noti che ci sono due punti .

Soluzione 2: server rsh di vecchia scuola

Tuttavia, la configurazione era troppo complicata per me. Quindi ho appena installato e rsh-serversul mio laptop. Il richiamo di rsync sulla workstation -e rexecutilizza quindi rsh anziché ssh. Che quindi ha quasi raddoppiato le prestazioni a 44,6 MB / s , che è ancora lento. I rimbalzi velocità fra 58 MB / s e 33 MB / s , che indica ci possono essere alcuni problemi di controllo del buffer o congestione. Ma questo va oltre lo scopo di questa domanda.

Queste sono domande e risposte molto vecchie, ma manca una cosa importante: se si copiano dati già compressi o crittografati, disattivare la compressione.

Se i tuoi dati non sono né compressi né crittografati, vuoi comunque comprimerli solo una volta! Rsync comprime con -z, ssh comprime con -C (potrebbe essere di default). Non ho testato il che è meglio poiché i miei dati sono compressi.

Mentre ci sono, puoi disattivare X forwarding e allocazione TTY, risultando in:

rsync -avh -e "ssh -x -T -c arcfour -o Compression=no" $src $dst

Infine, assicurati (ad esempio l'utilizzo iptraf) di utilizzare effettivamente l'interfaccia di rete che ritieni di utilizzare. Con mia grande sorpresa ho notato che sul mio OSX l'SSS in uscita era vincolante per l'IP sull'interfaccia in uscita predefinita invece che per l'IP sull'interfaccia su cui i pacchetti dovevano essere indirizzati. La mia interconnessione diretta GB tra due laptop collegati anche tramite WiFi non veniva utilizzata. Dopo le indagini, era dovuto all'utilizzo di 169.254 / 16, che il Mac inseriva su tutte le interfacce e che il computer di destinazione rispondeva alle richieste ARP anche se la richiesta arrivava su un'interfaccia diversa.