Pourquoi mon rsync est si lent?

42

Mon ordinateur portable et mon poste de travail sont tous deux connectés à un commutateur Gigabit. Les deux fonctionnent sous Linux. Mais lorsque je copie des fichiers avec rsync, cela fonctionne mal.

Je reçois environ 22 Mo / s. Ne devrais-je pas théoriquement avoir environ 125 Mo / s? Quel est le facteur limitant ici?

EDIT: J'ai mené des expériences.

Ecrire des performances sur l'ordinateur portable

L'ordinateur portable a un système de fichiers xfs avec chiffrement intégral du disque. Il utilise le aes-cbc-essiv:sha256mode de chiffrement avec une longueur de clé de 256 bits. Les performances d'écriture sur le disque sont de 58,8 Mo / 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

Performances de lecture sur le poste de travail

Les fichiers que j'ai copiés se trouvent sur un logiciel RAID-5 sur 5 disques durs. Au sommet du raid est un lvm. Le volume lui-même est crypté avec le même chiffre. Le poste de travail dispose d'un processeur FX-8150 doté d'un jeu d'instructions AES-NI natif qui accélère le cryptage. Les performances de lecture du disque sont de 256 Mo / s (le cache était froid).

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

La performance du réseau

J'ai couru iperf entre les deux clients. Les performances du réseau sont de 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
iblue
la source
3
rsync: // protocole ou tunnel sur SSH? Il existe des limitations de performances très précises dans ce dernier ¹ .
éphémère

Réponses:

18

Un autre moyen de limiter l'utilisation élevée du processeur tout en conservant la fonctionnalité de rsync consiste à passer de rsync / SSH à rsync / NFS. Vous pouvez exporter les chemins que vous souhaitez copier via NFS, puis utiliser rsync localement du montage NFS vers votre emplacement de destination.

Dans un test effectué sur un disque réseau WD MyBook Live, un ou plusieurs rsync du NAS sur un réseau Gigabit vers 2 disques USB locaux ne copieraient pas plus de 10 Mo / s (CPU: 80% usr, 20% sys), après exportation sur NFS et rsynchronisation locale du partage NFS vers les deux disques, j'ai obtenu un total de 45 Mo / s (maximum sur les disques USB2) et une faible utilisation du processeur. L'utilisation du disque avec rsync / SSH était d'environ 6% et celle de rsync / NFS était plus proche de 24%, tandis que celle des deux disques USB2 était proche de 100%.

Nous avons donc efficacement déplacé le goulot d'étranglement du processeur NAS vers les deux disques USB2.

Dag Wieers
la source
4
Sachez cependant que NFS n'offre aucune sécurité (c'est-à-dire: le cryptage).
WhyNotHugo
Cela a très bien fonctionné! Maintenant, obtenir des vitesses presque complètes lorsque je ne faisais que ~ 100 Mb / s auparavant.
PHLAK
1
Pourriez-vous indiquer comment utiliser rsync / NFS? J'essaie de transférer 8 To entre 2 disques MyCloud et cela prend une éternité avec rsync sur SSH (4Mo / sec)
FMaz008
26

Les raisons peuvent inclure: la compression, le cryptage, le nombre et la taille des fichiers copiés, les capacités d'E / S disque de vos systèmes source et cible, la surcharge TCP ... Tous ces facteurs peuvent influer sur le type de transfert que vous effectuez.

Veuillez publier la commande rsync que vous utilisez et fournir des détails sur les spécifications des deux ordinateurs.


Edit: Le cryptage est souvent un facteur limitant de la vitesse de rsync. Vous pouvez utiliser ssh et un chiffrement de chiffrement plus léger, commearcfour

Quelque chose comme: rsync -e "ssh -c arcfour"

Ou vous pouvez utiliser un rsync / ssh modifié pouvant désactiver le cryptage. Voir hpn-ssh: http://psc.edu/networking/projects/hpn-ssh

Mais encore une fois, votre ordinateur portable a un lecteur lent comparé à votre poste de travail. Les écritures peuvent être bloquées et attendre que les E / S soient envoyées sur votre ordinateur portable. Quelles sont vos attentes réelles en matière de performance?

ewwhite
la source
1
Les ordinateurs portables ont souvent des disques plus lents (7200 tr / min - 5 400 tr / min) car ils consomment moins d'énergie. Cela pourrait facilement être votre facteur limitant en fonction de ce que fait rsync.
Ladadadada
1
Merci. Pour rsyncningpartir d' un dm-crypt disque crypté attaché à un atome processer à une ecryptfs boîte ARM NAS, cela a changé ma vitesse de transfert de 4Mo / s 6MiB / s. rsync --protocol=29 -auh --progress /mnt/esata/pics/ -e "ssh -c arcfour" diskstation:/volume1/picsMieux que rien.
Sébastien
Cette réponse. Passer de rsync -azP à rsync -aPe "ssh -c arcfour" a permis d'augmenter la vitesse de transfert de 4 Mo / s à 25 Mo / s entre deux disques MyCloud Mirror. La CPU de l'unité réceptrice est maintenant au maximum. (Pensez que cela signifie que je transfère aussi vite que l'unité peut écrire des données)
FMaz008
10

Après quelques essais supplémentaires, j'ai finalement trouvé la réponse moi-même. rsyncutilise le tunneling sur ssh par défaut. La crypto le ralentit. Donc, je devais contourner ce genre de crypto.

Solution 1: configuration d'un serveur rsync

Pour l'utiliser via le rsyncprotocole, vous devez configurer un serveur rsyncd. Il y avait un /etc/init.d/rsyncscript sur mon ordinateur portable, donc je suppose que rsyncd était en cours d'exécution. J'avais tort. /etc/init.d/rsync startexiste silencieusement, lorsque rsync n’est pas activé dans /etc/default/rsync. Ensuite, vous devez également le configurer /etc/rsyncd.conf, ce qui est pénible.

Si vous faites tout cela, vous devez utiliser rsync file.foo user@machine::directory. Veuillez noter qu'il y a deux colons .

Solution 2: serveur rsh old-school

Cependant, la configuration était trop compliquée pour moi. Donc, je viens d'installer et rsh-serversur mon ordinateur portable. Invoquer rsync sur le poste de travail avec -e rexecensuite utilise rsh au lieu de ssh. Ce qui a ensuite presque doublé la performance à 44,6 Mo / s , ce qui est encore lent. La vitesse varie entre 58 Mo / s et 33 Mo / s , ce qui indique qu'il peut y avoir des problèmes de mémoire tampon ou de contrôle d'encombrement. Mais cela dépasse le cadre de cette question.

iblue
la source
2
Nous utilisons abondamment rsync ici et obtenons généralement une vitesse d'interface optimale, sauf si vous parcourez des millions de fichiers 4K. Je ne pense pas que le problème réside dans la crypto, sauf si vous utilisez du matériel sérieusement délabré.
Magellan
Un processeur Intel Core2 Duo T8100 dans un ThinkPad R61 compte-t-il comme matériel sérieusement délabré? Sinon, pourquoi rsync over ssh est-il plus lent que rsync over rsh?
iblue
5
Le chiffrement est souvent un facteur limitant de la vitesse de rsync, ainsi que du nombre de fichiers. Les approches standard pour améliorer cela consistent à exécuter rsync avec un chiffrement de chiffrement plus léger, rsync -e "ssh -c arcfour"ou à essayer une modification rsync / ssh pouvant désactiver le chiffrement. Voir hpn-ssh: psc.edu/networking/projects/hpn-ssh
ewwhite le
2

Il s'agit d'une très vieille question et de réponses, mais il manque un élément important: si vous copiez des données déjà compressées ou chiffrées, désactivez la compression.

Si vos données ne sont ni compressées ni cryptées, vous ne voulez toujours les compresser qu'une seule fois! Rsync compresse avec -z, ssh compresse avec -C (peut être par défaut). Je n'ai pas testé ce qui est mieux depuis que mes données sont compressées.

Tant que j'y suis, vous pouvez désactiver le transfert X et l'allocation de TTY, ce qui entraîne:

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

Enfin, assurez-vous (par exemple en utilisant iptraf) que vous utilisez réellement l'interface réseau que vous pensez utiliser. À ma grande surprise, j'ai remarqué que sur mon OSX, la ssh sortante était liée à l'IP sur l'interface sortante par défaut plutôt qu'à l'IP sur l'interface sur laquelle les paquets devaient être acheminés. Mon interconnexion directe GB entre deux ordinateurs portables également connectés par WiFi n'était pas utilisée. Après enquête, il était dû à l'utilisation de 169.254 / 16, que le Mac met sur toutes les interfaces, et à l'ordinateur de destination répondant aux demandes ARP, même si la demande est arrivée sur une interface différente.

Law29
la source
Options valides, mais je trouve que -x -T et -o Compression = no n’a eu que peu d’effets sur la vitesse de transfert.
FMaz008
4
Il est également intéressant de noter que OpenSSH 6.7 désactive arcfour.
bparker
C'est un peu dommage @bparker! Savons-nous lequel des chiffres restants est le plus léger sur le processeur?
Law29