Soluzione 1:
I motivi possono includere:compressione, crittografia, numero e dimensione dei file copiati, capacità di I/O del disco dei sistemi di origine e di destinazione, overhead TCP... Questi sono tutti fattori che possono influenzare il tipo di trasferimento che stai conducendo.
Pubblica il comando rsync che stai utilizzando e fornisci dettagli sulle specifiche di entrambi i computer.
Modifica:la crittografia è spesso un fattore limitante nelle velocità di rsync. Puoi eseguire con ssh e una cifratura di crittografia più leggera come arcfour
Qualcosa come: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'unità lenta rispetto alla tua workstation. Le scritture potrebbero essere bloccate e in attesa che l'I/O vada al tuo laptop. Quali sono le tue reali aspettative di performance?
Soluzione 2:
Un altro modo per mitigare l'elevato utilizzo della CPU mantenendo comunque la funzionalità di rsync è passare da rsync/SSH a rsync/NFS. Puoi esportare i percorsi da cui desideri copiare tramite NFS e quindi utilizzare rsync localmente dal montaggio NFS alla 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 copiavano più di 10 MB/sec (CPU:80% usr, 20% sys), dopo aver esportato oltre NFS e rsyncing localmente dalla condivisione NFS su entrambi i dischi Ho ottenuto un totale di 45 MB/sec (massimo entrambi i dischi USB2) e poco utilizzo della CPU. L'utilizzo del disco quando si utilizzava 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 effettivamente spostato il collo di bottiglia dalla CPU del NAS a entrambi i dischi USB2.
Soluzione 3:
Dopo qualche altro test, ho finalmente trovato la risposta da solo. rsync utilizza il tunneling su ssh per impostazione predefinita. La crittografia lo rende lento. Quindi avevo bisogno di aggirare quella roba crittografica.
Soluzione 1:configurazione di un server rsync
Per usarlo tramite il rsync protocollo, devi impostare un server rsyncd. C'era un /etc/init.d/rsync script sul mio laptop, quindi ho indovinato, rsyncd era in esecuzione. Mi sbagliavo. /etc/init.d/rsync start esiste silenziosamente, quando rsync non è abilitato in /etc/default/rsync . Quindi devi anche configurarlo in /etc/rsyncd.conf , che è una seccatura.
Se riesci a fare tutto questo, devi usare rsync file.foo [email protected]::directory . Tieni presente che ci sono due due punti .
Soluzione 2:server rsh vecchio stile
Tuttavia, la configurazione era troppo complicata per me. Così ho appena installato e rsh-server sul mio portatile. Richiamo di rsync sulla workstation con -e rexec quindi usa rsh invece di ssh. Che poi ha quasi raddoppiato le prestazioni a 44,6 MB/s , che è ancora lento. La velocità rimbalza tra 58 MB/s e 33 MB/s , che indica che potrebbero esserci problemi di buffer o di controllo della congestione. Ma questo va oltre lo scopo di questa domanda.
Soluzione 4:
Queste sono domande e risposte molto vecchie, ma manca una cosa importante:se stai copiando dati già compressi o crittografati, disattiva la compressione.
Se i tuoi dati non sono né compressi né crittografati, vuoi comprimerli solo una volta! Rsync comprime con -z, ssh comprime con -C (potrebbe essere di default). Non ho testato quale sia la migliore poiché i miei dati sono compressi.
Già che ci sono, puoi disattivare l'inoltro X e l'allocazione TTY, risultando in:
rsync -avh -e "ssh -x -T -c arcfour -o Compression=no" $src $dst
Infine, assicurati (ad esempio utilizzando iptraf ) che stai effettivamente utilizzando l'interfaccia di rete che pensi di utilizzare. Ho notato con mia grande sorpresa che sul mio OSX l'ssh in uscita si legava all'IP sull'interfaccia in uscita predefinita invece che all'IP sull'interfaccia su cui i pacchetti dovevano essere instradati. La mia connessione incrociata GB diretta tra due laptop collegati anche tramite WiFi non veniva utilizzata. Dopo le indagini, era dovuto all'utilizzo di 169.254/16, che il Mac mette su tutte le interfacce, e al computer di destinazione che rispondeva alle richieste ARP anche se la richiesta arrivava su un'interfaccia diversa.