Existe-t-il une alternative plus rapide à cp pour copier des fichiers volumineux (~ 20 Go)?

% CPU devrait être faible lors dune copie. Le CPU dit au contrôleur de disque « dextraire les données des secteurs X – Y dans la mémoire tampon en Z ». Ensuite, il va faire autre chose (ou dormir, sil ny a rien dautre). Le matériel déclenche une interruption lorsque les données sont en mémoire. Ensuite, le CPU doit le copier plusieurs fois et dit à la carte réseau « transmettre les paquets aux emplacements mémoire A, B et C ». Ensuite, il revient à faire autre chose.

Vous poussez ~ 240 Mbps.Sur un LAN Gigabit, vous devriez pouvoir faire au moins 800 Mbps, mais:

1. Cest partagé entre tous ceux qui utilisent le serveur de fichiers (et éventuellement une connexion entre commutateurs, etc.)
2. Cela est limité par la vitesse à laquelle le serveur de fichiers peut gérer l’écriture, en gardant à l’esprit que la bande passante d’E / S du disque est partagée par tous ceux qui l’utilisent.
3. Vous n’avez pas précisé comment vous accédez au serveur de fichiers (NFS, CIFS (Samba), AFS, etc.). Vous devrez peut-être régler le montage de votre réseau, mais pour tout ce qui est à moitié récent, les valeurs par défaut sont généralement saines.

Pour trouver le goulot détranglement, iostat -kx 10 va être une commande utile. Il « vous montrera lutilisation sur vos disques durs locaux. Si vous pouvez lexécuter sur le serveur de fichiers, cela » vous indiquera à quel point le serveur de fichiers est occupé.

La solution générale sera de accélérez ce goulot détranglement, pour lequel vous navez bien sûr pas le budget. Mais il existe quelques cas particuliers où vous pouvez trouver une approche plus rapide:

• Si les fichiers sont compressibles, et vous avez un processeur rapide, effectuer une compression minimale à la volée peut être plus rapide. Quelque chose comme lzop ou peut-être gzip --fastest.
• Si vous ne modifiez que quelques bits ici et là, puis que vous renvoyez le fichier, seul lenvoi de deltas sera beaucoup plus rapide. Malheureusement, rsync naidera pas vraiment ici, car il aura besoin de lire le fichier des deux côtés pour trouver le delta. Au lieu de cela, vous avez besoin de quelque chose qui garde la trace du delta lorsque vous modifiez le fichier … La plupart des approches ici sont spécifiques à lapplication. Mais il est possible que vous puissiez créer quelque chose avec, par exemple, un mappeur de périphériques (voir la toute nouvelle cible dm-era ) ou btrfs.
• Si vous copiez les mêmes données sur plusieurs machines, vous pouvez utiliser quelque chose comme udpcast pour les envoyer à toutes les machines à la fois.

Et, puisque vous notez que vous « nêtes pas ladministrateur système, je suppose que cela signifie que vous avez un administrateur système. Ou au moins quelquun responsable du réseau du serveur de fichiers &. Vous devriez probablement lui demander / elle / eux, ils devraient être beaucoup plus familiers avec les spécificités de votre configuration. Vos administrateurs système devraient au moins être en mesure de vous dire à quel taux de transfert vous pouvez raisonnablement vous attendre.

Commentaires

• +1 pour iostat -kx 10 🙂

Cela pourrait éventuellement être une alternative plus rapide, et vous ne bloquerez pas le réseau pendant deux jours: prenez un ou deux gros disques USB (USB 3 si vous en avez) ou FireWire, connectez-le à le serveur et copiez les fichiers sur le disque. Transportez le disque sur votre ordinateur local. Copiez les fichiers sur la machine.

Commentaires

• Sneakernet ( en.wikipedia.org/ wiki / Sneakernet ) peut être très rapide: ne sous-estimez jamais la bande passante dun break plein de bandes dévalant lautoroute.

Si vous avez un accès SSH (ou SFTP) direct (demandez à votre administrateur système), vous pouvez utiliser scp avec compression (-C):

scp -C you@server:/path/to/yourfile . 

Bien sûr, cela nest utile que si le fichier est compressible, et cela utilisera plus de temps CPU, car il utilisera le chiffrement (car il est sur SSH) et la compression.

Commentaires

• Dans ce cas, il serait utile de désactiver le cryptage. Noubliez pas que nous essayons de rendre la copie plus rapide .
• @lgeorget Je soupçonne que la surcharge du chiffrement ne sera ‘ significative , compte tenu de la lenteur des disques durs. Jai envisagé dajouter quelque chose à propos de -c none, mais cela ne semble pas standard .
• Nous ‘ traitons des fichiers d’environ 20 Go, il est donc inefficace d’utiliser le chiffrement si ce n’est pas nécessaire.
• @lgeorget Le chiffrement peut être fait beaucoup plus vite que le débit quil ‘ obtient, donc cela na pas ‘ ralentir quoi que ce soit. Mais il ne semble pas nécessaire de passer par SSH ici. Si vous avez juste besoin de compression, il existe sûrement dautres outils?
• @Thomas Lavantage de SSH est que si vous ‘ êtes censé avoir accès au serveur distant, alors il ‘ exécute presque certainement SSH. Une autre option serait de compresser le fichier localement, de le copier sur le serveur, puis de ssh et de le décompresser ..

Votre définition de lefficacité est à lenvers. Une implémentation plus efficace fait perdre moins de temps cpu. Sur la copie locale, vous obtenez en moyenne 74 Mo / s de débit (lecture + écriture), ce qui est à peu près aussi bon quun seul disque dur va lobtenir.

Commentaires

• Oups.Quand jai dit  » efficace,  » je voulais dire  » rapide.  »

Le cp la mise en œuvre nest probablement pas un goulot détranglement. Essayez dobserver lutilisation des E / S via iotop sur le serveur et le nœud de cluster. Cela vous donnera une idée où vous pouvez améliorer les performances.

Une autre astuce, est déviter de copier les mêmes données à partir du même hôte. Par exemple, si vous avez un fichier 20G identique à distribuer à partir du serveur de fichiers sur le réseau vers tous les nœuds du cluster, cela fonctionnera beaucoup plus rapidement si vous copiez les fichiers en mode peer-to-peer plutôt quen un seul serveur vers tous les clients. Cest un peu plus compliqué à implémenter, mais vous pouvez même essayer dutiliser une ligne de commande p2p comme le hub de connexion directe.

Si dans ces fichiers 20G, une partie est commune, et dautres sont spécifiques au nœud de cluster, considérez le diviser en parties communes et spécifiques, puis distribuer la partie commune de manière p2p.

Commentaires

• Si vous ‘ re sur un LAN, vous devriez pouvoir faire de la multidiffusion au lieu de peer-to-peer. Ce qui devrait être plus rapide et moins de charge sur le réseau.

La nature / le contenu de ces fichiers peuvent faire une différence. Jai compris que vous deviez copier 200 fichiers, denviron 20 Go chacun, dun ordinateur à un autre , cest ça?

Si ces fichiers sont compressibles ou avec des éléments similaires / identiques, vous avez deux approches:

• zippez-les avant de copier, ou créez un tunnel entre les ordinateurs avec zip activé. Donc, si le réseau est le goulot détranglement, ce sera un peu plus rapide r

• si les fichiers sont très similaires ou partagent des éléments communs entre eux, essayez dutiliser rsync . Il « passera un certain temps à trouver ce qui est commun parmi les fichiers, et naura pas besoin de le copier littéralement , car il » le reconstruira en fonction de ce qui est commun.

edit

Aurez-vous besoin de copier ces fichiers plusieurs fois ?? (comme une copie -> utilisez ces fichiers -> changez quelque chose dans les fichiers dans lordinateur A -> copiez à nouveau les fichiers sur lordinateur B)

Si tel est le cas, rsync sera utile, car il « essaiera de détecter ce qui est égal entre les versions et ne copiera pas ce qui est inchangé.

Et une troisième méthode: si ce qui précède est correct (changements dans le fichier, puis recopiez tous les fichiers sur le deuxième ordinateur), vous pouvez essayer quelques binary diff changer dans le deuxième ordinateur ce qui a été changé dans le premier ordinateur.

Je vois ce qui suit ici, le chiffrement nest pas un bonne idée car cela pourrait éventuellement AUGMENTER la quantité de données à transférer.

Si vous copiez entre deux systèmes, le goulot détranglement est bien sûr t la connexion entre les serveurs.

Si vous copiez localement, regardez comment le processus se déroule, il est UNIQUE thread, donc les utilitaires Linux standard utilisent:

- for all blocks in a file read a block write a block 

Il ny a AUCUNE concurrence pour cette opération.

Pour accélérer les choses, vous pouvez utiliser quelque chose comme ceci:

 buffer -i infile -o outfile -m size-of-shared-memory-default-1MByte 

Voir la page de manuel de buffer (1) pour plus dinformations.

La commande buffer met en place deux processus pour exécuter le processus de copie simultanément: un pour la lecture et lautre pour lécriture, et elle utilise un tampon de mémoire partagée pour communiquer les données entre les deux processus. Le tampon de mémoire partagée est votre tampon circulaire classique qui empêche lécrasement des données non écrites et lécriture des données déjà écrites. Jai utilisé ce programme pour couper environ 10 à 20% du temps de copie dans les transferts de disque à bande.

Commentaires

• En fait, il y a concurrence dans  » lire un bloc / écrire un bloc  » car  » écrire un bloc  » le met simplement dans le tampon du noyau ‘, et le noyau gère lécriture de bloc réelle en arrière-plan (au moins, jusquà ce que vous commencez à manquer de RAM). Ou si vous utilisez O_DSYNC / O_SYNC pour une raison quelconque.

Pourquoi ne pas essayer un algorithme de propagation P2P , si vous devez mettre à jour lintégralité de votre cluster en même temps?

https://github.com/lg/murder est ce que Twitter utilise

Il existe des BTSync que vous pouvez également essayer.

Si vous « copiez fréquemment les mêmes ensembles de fichiers depuis votre ordinateur local vers le serveur avec des modifications mineures ici et là. Vous pouvez accélérer le transfert en utilisant rsync ou un DVCS (par exemple hg ou git).

git ou hg peut garder une trace et détecter les deltas et ne transférer que ces deltas. En cas dutilisation dun git, étant donné que les deux côtés ont lhistorique complet du référentiel, déterminer le delta est très bon marché.

rsync utilise une forme dalgorithme de cumul de contrôle pour détecter les deltas sans connaissance préalable de ce qui se trouve de lautre côté. Bien que rsync demande plus de travail pour calculer les deltas, il na pas besoin de stocker le tout historique des fichiers.

Vous voudrez peut-être essayer de regrouper tous les fichiers dans une seule archive (ne doit pas être compressée). Daprès mon expérience, copier cette archive est plus rapide que copier un grand nombre de fichiers individuels

Commentaires

• Bonne observation générique, mais comme le dit la question «~ 200 gros fichiers – chacun ~ 20 Go», je ne ‘ pas que cela puisse être considéré comme une véritable réponse à ce problème.
• @manatwork ah .. je nai ‘ pas lu clairement. Je pensais quil avait 200 fichiers totalisant 20 Go

Essayez bbcp . Les tests dans notre environnement ont révélé que cp avait une sorte de o f intégré dans le gouverneur. Faites juste attention car lorsque vous enlevez le régulateur, vous pouvez mettre en rouge votre serveur et provoquer une panne. Dans notre cas, nous prenions le serveur hors ligne pour faire la copie, donc plus vite était mieux. Cela a amélioré le temps de transfert de plusieurs heures.

Assurez-vous que la cible les fichiers nexistent pas avant la copie.

Parfois, il est surprenant de savoir combien de temps est passé ne serait-ce quà copier sur le même hôte (aucun réseau impliqué).

Voir ma réponse à une autre question cp ici . En bref, écraser un fichier existant est beaucoup plus lent que de le tronquer ou de le dissocier dabord, puis la copie. Cette dernière est 8 fois plus rapide pour un fichier de 1,2 Go.