Solution 1 :
Les raisons peuvent inclure :la compression, le cryptage, 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, la surcharge TCP... 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 les vitesses de rsync. 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 en attente d'E/S vers votre ordinateur portable. Quelles sont vos attentes réelles en termes de performances ?
Solution 2 :
Une autre façon d'atténuer 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 à partir desquels vous souhaitez copier via NFS, puis utiliser rsync localement depuis le montage NFS vers votre emplacement de destination.
Dans un test à partir d'un disque réseau WD MyBook Live, une 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 exportation sur NFS et synchronisation locale du partage NFS sur les deux disques, j'ai obtenu un total de 45 Mo/sec (maximisant les deux disques USB2) et peu d'utilisation du processeur. L'utilisation du disque avec rsync/SSH était d'environ 6 % et avec 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.
Solution 3 :
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 le rend lent. J'avais donc besoin de contourner ce truc de cryptographie.
Solution 1 :Configurer un serveur rsync
Pour l'utiliser via le rsync protocole, vous devez configurer un serveur rsyncd. Il y avait un /etc/init.d/rsync script sur mon ordinateur portable, alors j'ai deviné que rsyncd était en cours d'exécution. J'ai eu tort. /etc/init.d/rsync start existe silencieusement, lorsque rsync n'est pas activé dans /etc/default/rsync . Ensuite, vous devez également le configurer en /etc/rsyncd.conf , ce qui est pénible.
Si vous faites tout cela, vous devez utiliser rsync file.foo [email protected]::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. Donc je viens d'installer et rsh-server Sur mon ordinateur portable. Invoquer rsync sur le poste de travail avec -e rexec puis utilise rsh au lieu de ssh. Ce qui a ensuite presque doublé les performances à 44,6 Mo/s , qui est encore lent. La vitesse oscille 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.
Solution 4 :
Il s'agit d'une question et de réponses très anciennes, mais il manque une chose importante :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 voulez quand même 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 le mieux puisque mes données sont compressées.
Pendant que j'y suis, vous pouvez désactiver le transfert X et l'attribution TTY, ce qui donne :
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. 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 requêtes ARP même si la requête arrivait sur une interface différente.