Pourquoi ma rsync est-elle si lente?
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.
J'obtiens environ 22 Mo/s. Ne devrais-je pas théoriquement obtenir environ 125 Mo/s? Quel est le facteur limitant ici?
EDIT: J'ai mené quelques expériences.
Écrire les performances sur l'ordinateur portable
L'ordinateur portable dispose d'un système de fichiers xfs avec cryptage complet du disque. Il utilise aes-cbc-essiv:sha256 mode de chiffrement avec une longueur de clé de 256 bits. Les performances d'écriture sur disque sont 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
Lire les performances 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 chiffré avec le même chiffre. La station 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 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
Performances du réseau
J'ai couru iperf entre les deux clients. Les performances du réseau sont 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
Une autre façon d'atténuer l'utilisation élevée du processeur tout en conservant les fonctionnalités de rsync consiste à passer de rsync/SSH à rsync/NFS. Vous pouvez exporter les chemins à partir desquels vous souhaitez copier via NFS, puis utiliser rsync localement du montage NFS vers votre emplacement de destination.
Dans un test à partir d'un disque réseau WD MyBook Live, un ou plusieurs rsyncs du NAS sur un réseau Gigabit vers 2 disques USB locaux ne copieraient pas plus de 10 Mo/sec (CPU: 80% usr , 20% sys), après avoir exporté via NFS et rsynced localement à partir du partage NFS vers les deux disques, j'ai obtenu un total de 45 Mo/sec (maximisation des deux disques USB2) et peu d'utilisation du processeur. L'utilisation du disque lors de l'utilisation de rsync/SSH était d'environ 6 % et l'utilisation de rsync/NFS était plus proche de 24%, tandis que les deux disques USB2 étaient proches de 100%.
Nous avons donc effectivement déplacé le goulot d'étranglement du processeur NAS vers les deux disques USB2).
Les raisons peuvent être: la compression, le chiffrement, le nombre et la taille des fichiers copiés, les capacités d'E/S du disque de vos systèmes source et de destination, TCP surcharge ... Ce sont tous des facteurs qui peuvent influencer 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.
Modifier: le cryptage est souvent un facteur limitant des vitesses de synchronisation. Vous pouvez exécuter avec ssh et un chiffrement de chiffrement plus léger comme arcfour
Quelque chose comme: rsync -e "ssh -c arcfour"
Ou vous pouvez utiliser un rsync/ssh modifié qui peut 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 par rapport à votre poste de travail. Les écritures peuvent être bloquées et attendre que les E/S se dirigent vers votre ordinateur portable. Quelles sont vos réelles attentes de performance?
Après quelques tests supplémentaires, j'ai finalement trouvé la réponse moi-même. rsync utilise le tunneling sur ssh par défaut. La crypto la rend lente. J'avais donc besoin de contourner ce crypto.
Solution 1: configuration d'un serveur rsync
Pour l'utiliser via le protocole rsync, vous devez configurer un serveur rsyncd. Il y avait un /etc/init.d/rsync script sur mon ordinateur portable, donc je suppose que rsyncd était en cours d'exécution. J'avais tort. /etc/init.d/rsync start existe silencieusement, lorsque rsync n'est pas activé dans /etc/default/rsync. Ensuite, vous devez également le configurer dans /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 deux-points.
Solution 2: serveur rsh à l'ancienne
Cependant, la configuration était beaucoup trop compliquée pour moi. Je viens donc d'installer et rsh-server Sur mon ordinateur portable. Appel de rsync sur le poste de travail avec -e rexec utilise alors rsh au lieu de ssh. Ce qui a ensuite presque doublé les performances à 44,6 Mo/s, ce qui est encore lent. La vitesse rebondit entre 58 Mo/s et 33 Mo/s , ce qui indique qu'il peut y avoir des problèmes de tampon ou de contrôle de congestion. Mais cela dépasse le cadre de cette question.
Ce sont des questions et réponses très anciennes, mais une chose importante manque: 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 car mes données sont compressées.
Pendant que j'y suis, vous pouvez désactiver le transfert X et l'allocation ATS, 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 bien l'interface réseau que vous pensez utiliser. J'ai à ma grande surprise noté que sur mon OSX, le ssh sortant était lié à l'IP sur l'interface sortante par défaut au lieu de l'IP sur l'interface sur laquelle les paquets étaient censés être acheminés. Ma connexion directe GB entre deux ordinateurs portables également connectés par WiFi n'était pas utilisée. Après enquête, cela é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 arrivait sur une interface différente.