Pourquoi mon rsync est-il si lent ?

Les raisons peuvent être : la compression, le cryptage, le nombre et la taille des fichiers copiés, les capacités d'E/S du disque de votre système source et de votre système de destination, la surcharge TCP... Tous ces facteurs peuvent influencer le type de transfert que vous effectuez.

Veuillez indiquer 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 la vitesse de rsync. Vous pouvez utiliser ssh et un chiffrement plus léger comme arcfour

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

Vous pouvez également utiliser un rsync/ssh modifié qui peut désactiver le cryptage. Voir hpn-ssh : http://psc.edu/networking/projects/hpn-ssh

Mais là encore, votre ordinateur portable a un disque lent par rapport à votre station de travail. Les écritures peuvent être bloquées et en attente d'E/S vers votre ordinateur portable. Quelles sont vos véritables attentes en matière de performances ?

Après quelques essais supplémentaires, j'ai finalement trouvé la réponse moi-même. rsync utilise par défaut le tunneling sur ssh. La cryptographie le rend lent. J'avais donc besoin de contourner ce problème de cryptographie.

Solution 1 : Mise en place d'un serveur rsync

Pour l'utiliser via le rsync vous devez mettre en place un serveur rsyncd. Il existait un /etc/init.d/rsync script sur mon ordinateur portable, j'ai donc supposé que rsyncd était en cours d'exécution. Je me suis trompé. /etc/init.d/rsync start existe silencieusement, lorsque rsync n'est pas activé dans le fichier /etc/default/rsync . Ensuite, vous devez également le configurer dans /etc/rsyncd.conf ce qui est pénible.

Si vous parvenez à faire 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. J'ai donc simplement installé et rsh-server sur mon ordinateur portable. En invoquant rsync sur le poste de travail avec -e rexec utilise alors rsh au lieu de ssh. Ce qui a presque doublé les performances à 44,6 Mo/s ce qui est encore lent. La vitesse oscille entre 58 Mo/s et 33 MB/s ce qui indique qu'il peut y avoir des problèmes de mémoire tampon ou de contrôle de la congestion. Mais cela dépasse le cadre de cette question.

Ces questions et réponses sont très anciennes, mais une chose importante manque : si vous copiez des données déjà compressées ou cryptées, désactivez la compression.

Si vos données ne sont ni compressées ni cryptées, vous ne devez les compresser qu'une seule fois ! Rsync compresse avec -z, ssh compresse avec -C (peut-être par défaut). Je n'ai pas testé lequel est le meilleur puisque mes données sont compressées.

Pendant que j'y suis, vous pouvez désactiver le transfert de X et l'attribution de TTY, ce qui se traduit par :

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. À ma grande surprise, j'ai constaté que sur mon OSX, le ssh sortant se liait à l'IP de l'interface sortante par défaut au lieu de l'IP de 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 place sur toutes les interfaces, et à l'ordinateur de destination qui répondait aux requêtes ARP même si la requête provenait d'une interface différente.