.. lorsqu'il transfère un gros fichier, il atteint environ 11 Mo/s.
Sans le savoir, vous pourriez avoir causé un transfert partiel en comparant les taux de transfert, ce qui pourrait ralentir le CPU.
Rsync effectue par défaut un transfert delta s'il détecte un fichier partiel sur le récepteur (restant du test scp
?). La méthode de "checksum roulant" pour comparer ce qui doit être transféré va se traduire par une utilisation accrue du CPU du côté de l'expéditeur.
J'ai remarqué une diminution de 4 fois du taux de transfert sur un gros fichier binaire partiel avec un CPU faible en tant qu'expéditeur (Intel Atom ou des instances VM plus petites). Sur des machines plus puissantes, le taux de transfert est resté stable après l'analyse initiale du fichier partiel lors de la poursuite du transfert. La différence de débit par rapport à netcat
devrait provenir du chiffrement via ssh.
Indiquer explicitement à rsync de ne pas utiliser de transferts partiels (-W|--whole-file
) ramènera les taux de transfert dans la même fourchette. Si nécessaire, --append
est une autre manière de reprendre un transfert de fichier interrompu sans provoquer de transfert delta. get -a
dans sftp
permet également de reprendre un téléchargement.
Consultez la description de l'architecture de Rsync pour plus d'explications.