Pourquoi le SCP est-il si lent et comment le rendre plus rapide?

59

J'essaie de copier un lot de fichiers avec scpmais c'est très lent. Ceci est un exemple avec 10 fichiers:

$ time scp cap_* user@host:~/dir
cap_20151023T113018_704979707.png    100%  413KB 413.2KB/s   00:00    
cap_20151023T113019_999990226.png    100%  413KB 412.6KB/s   00:00    
cap_20151023T113020_649251955.png    100%  417KB 416.8KB/s   00:00    
cap_20151023T113021_284028464.png    100%  417KB 416.8KB/s   00:00    
cap_20151023T113021_927950468.png    100%  413KB 413.0KB/s   00:00    
cap_20151023T113022_567641507.png    100%  413KB 413.1KB/s   00:00    
cap_20151023T113023_203534753.png    100%  414KB 413.5KB/s   00:00    
cap_20151023T113023_855350640.png    100%  412KB 411.7KB/s   00:00    
cap_20151023T113024_496387641.png    100%  412KB 412.3KB/s   00:00    
cap_20151023T113025_138012848.png    100%  414KB 413.8KB/s   00:00    
cap_20151023T113025_778042791.png    100%  413KB 413.4KB/s   00:00    

real    0m43.932s
user    0m0.074s
sys 0m0.030s

La chose étrange est que le taux de transfert est d’environ 413 Ko / s et que la taille du fichier est d’environ 413 Ko; il faut donc vraiment transférer un fichier par seconde, mais cela prend environ 4,3 secondes par fichier.

Avez-vous une idée de la provenance de ce temps système et existe-t-il un moyen de le rendre plus rapide?

scp time batch-jobs

— laurent
source

3

À quelle vitesse vous attendez-vous (c.-à-d. Existe-t-il un autre protocole qui indique des vitesses de transfert plus élevées entre les deux mêmes machines)? Que se passe-t-il lorsque vous scp un fichier beaucoup plus volumineux (peut-être la concaténation de tous vos fichiers de 413 Ko)?

— Dhag

6

Il semble que le système distant tente peut-être de résoudre l'adresse IP du client en un nom et que vous deviez attendre un délai d'attente avant la fin de la session. Vous pouvez envisager de résoudre ce problème (par exemple, ajoutez votre adresse IP au fichier / etc / hosts de la destination).

— Wurtel

4

Il est à noter que le drapeau -C permet la compression pendant le transfert. Bien que votre problème semble être lié au démarrage des transferts, la compression est fondamentalement "libre" et aide presque toujours.

— Sam

@wurtel: Je ne vois pas ce que vous voyez, tout ce que je vois, ce sont des moments. De toute façon, un seul appel DNS inversé ne devrait être nécessaire.

— James réintègre Monica Polk

Comptez-vous sur SCP pour la sécurité ou uniquement pour la copie à distance?

— Freiheit

17

Le commentaire de @ wurtel est probablement correct: il y a beaucoup de frais généraux lors de l'établissement de chaque connexion. Si vous pouvez résoudre ce problème, vous obtiendrez des transferts plus rapides (et si vous ne le pouvez pas, utilisez simplement la rsyncsolution de contournement de @ roaima ). J'ai effectué une expérience en transférant des fichiers de taille similaire ( head -c 417K /dev/urandom > foo.1et en copiant certaines copies) vers un hôte qui met un certain temps à se connecter (HOST4) et qui répond très rapidement (HOST1):

$ time ssh $HOST1 echo


real    0m0.146s
user    0m0.016s
sys     0m0.008s
$ time scp * $HOST1:
foo.1                                         100%  417KB 417.0KB/s   00:00    
foo.2                                         100%  417KB 417.0KB/s   00:00    
foo.3                                         100%  417KB 417.0KB/s   00:00    
foo.4                                         100%  417KB 417.0KB/s   00:00    
foo.5                                         100%  417KB 417.0KB/s   00:00    

real    0m0.337s
user    0m0.032s
sys     0m0.016s
$ time ssh $HOST4 echo


real    0m1.369s
user    0m0.020s
sys     0m0.016s
$ time scp * $HOST4:
foo.1                                         100%  417KB 417.0KB/s   00:00    
foo.2                                         100%  417KB 417.0KB/s   00:00    
foo.3                                         100%  417KB 417.0KB/s   00:00    
foo.4                                         100%  417KB 417.0KB/s   00:00    
foo.5                                         100%  417KB 417.0KB/s   00:00    

real    0m6.489s
user    0m0.052s
sys     0m0.020s
$

1

Merci, c'est très intéressant. La sortie scp est un peu cassée si elle affiche la même heure même si elle est complètement différente d’un hôte à l’autre. Ils devraient probablement inclure le temps de connexion dans le temps total.

— laurent

1

Donc, votre hypothèse est-il d'établir une nouvelle connexion une fois pour chaque fichier?

— rogerdpack

59

Vous pouvez utiliser rsync(over ssh), qui utilise une seule connexion pour transférer tous les fichiers source.

rsync -avP cap_* user@host:dir

Si vous n'avez pas rsync(et pourquoi pas !?), vous pouvez utiliser taravec sshcomme ceci, ce qui évite de créer un fichier temporaire:

tar czf - cap_* | ssh user@host tar xvzfC - dir

Le rsyncdoit être préféré, toutes choses étant égales par ailleurs, car il peut être redémarré en cas d'interruption.

— Roaima
source

6

Voulez-vous dire qu'une seule scpinvocation n'utiliserait pas une seule connexion pour transférer tous les fichiers?

— un CVn

1

Dans le cas de tarpipe, il n’est pas nécessaire de les placer de f -chaque côté, car les sorties de tar vers / lit à partir de stdout / stdin par défaut. Alors tar cz cap_* | ssh user@host tar xvzC dirle ferais.

— tremby

1

@tremby pas nécessairement. tarpeut être compilé avec différentes valeurs par défaut (voyez tar --show-defaultssi vous utilisez GNU tar, ou /etc/default/tarautrement, et dans les deux cas, n'oubliez pas la TAPEvariable d'environnement)

— roaima

1

@ MichaelKjörling au départ, j'avais supposé que scpcela créerait une nouvelle connexion pour chaque fichier, mais au souvenir - et après un double contrôle avec tshark- j'ai réalisé que je n'étais pas correct. À ce stade, je ne sais plus trop pourquoi les PO scpdevraient prendre un temps aussi long par fichier.

— Roaima

@ Raima, intéressant, merci. Je n'ai jamais remarqué que stdin / stdout n'était pas par défaut jusqu'à présent. BSD tar sur mon Mac au travail ne mentionne pas une variable env. TAPE dans sa page de manuel, contrairement à la tar GNU sur ma machine Linux.

— Tremby

15

C'est la négociation du transfert qui prend du temps. En général, les opérations sur n fichiers de b octets prennent beaucoup plus de temps qu'une seule opération sur un fichier unique de n * b octets. Ceci est également vrai, par exemple, pour les E / S de disque.

Si vous regardez attentivement, vous verrez que le taux de transfert dans ce cas est size_of_the_file / secs.

Pour transférer des fichiers plus efficacement, regroupez-les avec tar, puis transférez l'archive:

tar cvf myarchive.tar cap_20151023T*.png

ou, si vous voulez aussi compresser l'archive,

tar cvzf myarchive.tar.gz myfile*

Compresser ou non dépend du contenu du fichier, par exemple. si ce sont des JPEG ou des PNG, la compression n'aura aucun effet.

— dr01
source

Les PNG utilisent deflate, et les gzipper est inutile aussi.

— Arthur2e5

Je dirais que, parce que la compression du fichier tar n'a pas d'effet négatif lorsque les fichiers ne peuvent plus être compressés, c'est une bonne pratique-z

— Centimane

1

@Dave s'ils ne peuvent pas être compressés, ou si le réseau est rapide, cela ralentira les choses.

— Davidmh

@ Davidmh serait-ce un montant considérable cependant? Je penserais que compresser un fichier déjà compressé serait assez rapide, car il ne ferait que regarder ce qu'il pourrait compresser et constater que ce n'est rien. Cela dépend si je fais tarnormalement une deuxième passe pour la compression ou si nous compressions et archivions en même temps

— Centimane

3

@Dave dans mon cas (données sur un disque dur moderne de 7 000 tr / min, processeur haut de gamme, réseau très rapide, rien de plus vantard), tar sans compression est purement lié à l'IO, mais avec un -zprocesseur lié, et beaucoup plus lent. gzip essaiera toujours de compresser, d’où le ralentissement; Après tout, vous ne pouvez pas savoir si une chaîne d'octets est compressible avant d'avoir essayé de la compresser. Dans ma configuration, même lors du transfert de fichiers en texte brut, rsync sans compression est le facteur le plus rapide par 2 à 3 comparé à la compression la plus légère. Bien sûr, YMMV.

— Davidmh

6

Une autre raison de la lenteur de scp, en particulier sur les réseaux à bande passante élevée, réside dans le fait qu'il dispose de mémoires tampons internes de contrôle de flux définies de manière statique qui finissent par devenir des goulots d'étranglement des performances du réseau.

HPN-SSH est une version patchée d'OpenSSH qui augmente la taille de ces tampons. La vitesse de transfert SCP fait une énorme différence (voir les tableaux sur le site, mais je parle aussi par expérience personnelle). Bien entendu, pour bénéficier des avantages nécessaires à l’installation de HPN-SSH sur tous vos hôtes, cela vaut le coup si vous devez régulièrement transférer des fichiers volumineux.

— Menno Smits
source

5

J'ai utilisé la technique décrite ici qui utilise gzip en parallèle et netcat pour compresser et copier rapidement des données.

Cela revient à:

# SOURCE: 
> tar -cf - /u02/databases/mydb/data_file-1.dbf | pigz | nc -l 8888

# TARGET:
> nc <source host> 8888 | pigz -d | tar xf - -C /

Ceci utilise tar pour rassembler le ou les fichiers. Ensuite, utilise pigz pour compresser et envoyer de nombreux threads cpu, la transmission réseau utilisant netcat. Du côté de la réception, netcat écoute puis décompresse (en parallèle) et décompresse.

— Freiheit
source

3

ncn'est pas crypté. Ajouter de la ssh -Dmagie peut-être?

— Arthur2e5

c'est en fait assez brillant

— Jabran Saeed

5

Je viens tout juste d’avoir ce problème lors du transfert d’un grand fichier mp4 de site à site scp. Obtenait ~ 250KB / s. Une fois la protection UDP Flood désactivée sur le pare-feu de destination, le taux de transfert a atteint 6,5 Mo / s. Lors de la remise en marche de la FP, le débit est tombé à environ 250 Ko / s.

Expéditeur: cygwin, destinataire: Fedora 20, pare-feu Sophos UTM.

Pourquoi SSH utilise-t-il UDP? @ superuser.com - Cela ne découle pas directement de ce que j'ai lu.

Lors de l'examen du journal du pare-feu, la détection d'inondation se produisait à la fois sur les ports source et de destination 4500 sur les adresses IP publiques, et non sur les adresses VPN internes de site à site privé. Il semble donc que mon problème est probablement une situation de NAT Traversal où les scpdonnées TCP sont finalement cryptées et encapsulées dans des paquets ESP et UDP, et par conséquent soumises à la PF. Pour supprimer scpl'équation, j'ai exécuté une opération de copie de fichier Windows sur le VPN et j'ai constaté des performances similaires à celles scpavec et sans la fonction FP activées. Également exécuté un iperftest sur TCP et remarqué 2 Mbits / s avec FP, et 55 Mbits / s sans.

Comment NAT-T fonctionne-t-il avec IPSec? @ cisco.com

— bvj
source