Pourquoi mon rsync est si lent?

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

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.

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?

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.

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.