J'ai besoin de transférer une énorme quantité de mp3s entre deux serveurs (Ubuntu). Par énorme, j'entends environ un million de fichiers qui font en moyenne 300K. J'ai essayé avec scp mais cela aurait pris environ une semaine. (environ 500 KB/s) Si je transfère un seul fichier par HTTP, j'obtiens 9-10 MB/s, mais je ne sais pas comment les transférer tous.
Existe-t-il un moyen de les transférer tous rapidement ?
Avec beaucoup de fichiers, si vous optez pour rsync, J'essaierais d'obtenir la version 3 ou supérieure des deux côtés. . La raison en est qu'une version inférieure énumère chaque fichier avant de lancer le transfert. La nouvelle fonctionnalité s'appelle récursion incrémentale .
Un nouvel algorithme de récursion incrémentale est maintenant utilisé lorsque rsync parle à une autre version 3.x. Cela permet de démarrer le transfert plus rapidement (avant que tous les fichiers aient été trouvés), et nécessite beaucoup moins de mémoire. Voir l'option --recursive dans la page de manuel pour quelques restrictions.
Le processeur ne sera pas un goulot d'étranglement, sauf si vous disposez d'un réseau Ethernet 10G et d'un processeur vieux de 10 ans.
Lors de la copie d'un grand nombre de fichiers, j'ai constaté que des outils comme tar et rsync sont plus inefficaces qu'ils ne devraient l'être en raison des frais généraux liés à l'ouverture et à la fermeture de nombreux fichiers. J'ai écrit un outil open source appelé fast-archiver qui est plus rapide que tar pour ces scénarios : https://github.com/replicon/fast-archiver ; il travaille plus rapidement en effectuant plusieurs opérations de fichiers simultanées.
Voici un exemple de comparaison entre fast-archiver et tar sur une sauvegarde de plus de deux millions de fichiers ; fast-archiver prend 27 minutes pour archiver, contre 1 heure 23 minutes pour tar.
$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps
$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swapsPour transférer des fichiers entre serveurs, vous pouvez utiliser fast-archiver avec ssh, comme ceci :
ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x
Une autre alternative est Unison . pourrait être légèrement plus efficace que Rsync dans ce cas, et il est un peu plus facile de mettre en place un listener.
Unison est la meilleure alternative que j'ai trouvée pour copier de gros volumes de fichiers sur le réseau. Rsync n'est pas multithread et ne copie qu'un seul fichier à la fois. Il existe une version multithread de rsync mais elle est très difficile à utiliser, Unison a une fonction de traitement par lots et synchronise les fichiers en arrière-plan.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
1 votes
Quel type de réseau avez-vous entre les serveurs ? J'ai utilisé un croisement Ethernet GB entre 1 NIC dans chaque machine. J'ai obtenu un très bon résultat avec cette configuration en utilisant SCP.
0 votes
Vous pouvez chercher à savoir pourquoi scp est si lent. Il est peut-être plus lent que des choses comme ftp à cause du cryptage, mais il ne devrait pas être beaucoup plus lent.
0 votes
J'ai 100 mbps entre eux. scp est plus lent sur les petits fichiers (la plupart d'entre eux sont petits).