Pourquoi scp avec compression est-il plus lent que sans?

10

J'avais besoin de transférer un fichier vdisk KVM de 20 Go , stockant le système de fichiers racine d'une machine virtuelle CentOS 6.5, d'un serveur de laboratoire à un autre. La grande taille du fichier et le fait que j'avais déjà compressé un tel fichier vdisk à quelques centaines de méga-octets m'ont instinctivement permis la compression avec scpmais j'ai été surpris de voir une vitesse de transfert assez faible. Ensuite, j'ai essayé bzip2en combinaison avec sshet catet j'ai été surpris. Voici le résumé des méthodes et du débit moyen.

scp -C vm1-root.img root@192.168.161.62:/mnt/vdisks/, 11 Mo / s.
bzip2 -c vm1-root.img | ssh -l root 192.168.161.62 "bzip2 -d -c > /mnt/vdisks/vm1-root.img", 5 Mo / s. Ce résultat encore plus faible a incité à rechercher sur le Net.
scp -c arcfour -C vm1-root.img root@192.168.161.62:/mnt/vdisks/, 13 Mo / s. Cette utilisation de -c arcfouras a été suggérée dans une réponse sur serverfault. Cela n'a guère aidé. Enfin, j'ai désactivé la compression.
scp vm1-root.img root@192.168.161.62:/mnt/vdisks/, 23 Mo / s.

La compression n'aurait-elle pas dû être plus rapide?

EDIT: Je ne sais pas pourquoi la question a été rejetée. Je pensais qu'il y avait quelque chose à apprendre ici.

Après avoir reçu le ssh(1)conseil de la page de manuel de @sven, j'ai essayé quelques méthodes alternatives de transfert de fichiers n'impliquant pas de compression, les deux avec de meilleurs résultats.

cat vm1-root.img | ssh -l root 192.168.161.62 "cat > /mnt/vdisks/vm1-root.img", 26 Mo / s.
nc -l 5678 > /mnt/vdisks/vm1-root.imgsur le récepteur et nc 192.168.161.62 5678 < vm1-root.imgl'émetteur, 40 Mo / s. Le port 5678est arbitraire et disponible.

L'utilisation ncs'est avérée être la méthode de copie la plus rapide!

Dans le passé, scp -Ca très bien fonctionné chaque fois que je le pensais. Par exemple, lors du transfert de syslogs ( /var/log/messages*) de quelques Go de taille. Un taux de transfert non compressé de quelques centaines de Ko / s passerait à 1-2 Mo / s. Cet exemple tombe dans le cas d'une connexion lente comme cela a été souligné dans la page de manuel.

J'ai un cas où, une image vdisk nouvellement créée pour une partition de 20 Go a une taille compressée de seulement 200 Mo. Avec un taux de transfert d'environ 25 Mo / s, nous avons pu faire la copie en seulement 8 secondes au lieu de plus de 13 minutes! De toute évidence, scpsans compression est inefficace dans ce cas et scp -Cest encore pire.

Je suppose que la principale leçon apprise ici est que, scp -Cdevrait être considéré comme étant seulement une commodité. Si un fichier peut être compressé de manière significative, il est préférable de le compresser d'abord sur la source, de transférer le formulaire compressé et enfin de décompresser sur la destination. Les outils qui effectuent la compression et la décompression rapidement (par exemple pbzip2 ) seront d'une plus grande aide.

ssh scp file-transfer

— pdp
source

9

Citant man ssh(qui est la base utilisée par scp):

La compression est souhaitable sur les lignes de modem et autres connexions lentes, mais ne ralentira que les choses sur les réseaux rapides.

Le problème est que la compression des données prend plus de temps que leur envoi sur le réseau.

— Sven
source

Il demandait spécifiquement pourquoi le taux de transfert était plus bas, mais je soupçonne que ssh calcule réellement cela en divisant la taille des données par le temps total que prend toute l'opération, et en ne séparant pas la partie où il compresse les données et la partie où il copie les données sur le réseau.

— Ernie

@Ernie: Si vous pouvez transmettre des données à une vitesse de 20 Mo / s et que le système ne peut les livrer qu'avec 15 Mo / s car la compression est si lente, elles seront transmises avec seulement 15 Mo / s. C'est tout ce qu'on peut en dire.

— Sven

@Ernie: Le taux de transfert imprimé par scpinclut le temps passé en compression / décompression. Les valeurs déclarées sembleraient surprenantes si ce n'était pas le cas.

— pdp

0

De plus, en plus de la compression, nc obtient le meilleur taux car il ne crypte pas non plus. Et la compression sans perte repose sur la recherche de sections redondantes des données qui, lorsqu'elles sont effectuées au niveau du réseau, vous pouvez regarder un maximum de [taille de la mémoire tampon] octets alors que lorsque vous avez terminé avec le fichier entier en premier, ce sont des octets de [taille de fichier] dans lequel chasser et croquer des phrases d'octets en double.

De plus, pour déplacer des images de disque, vous devez utiliser un outil compatible avec le système de fichiers comme ntfsclone / partclone car même la compression ne peut pas battre simplement en ignorant les blocs non alloués - votre taux de transfert est infini si vous n'avez pas à transférer de données. N'oubliez pas non plus de détruire les fichiers de swap et d'hibernation sur une partition Windows ou vous copiez des fichiers inutiles, ils seront simplement jetés et recréés de toute façon.

— Tony Butler
source