Comment accélérer rsync pour les petits fichiers

15

J'essaie de transférer des milliers de petits fichiers d'un serveur à un autre à l'aide de la commande suivante:

rsync -zr --delete /home/user/ user@10.1.1.1::backup

Actuellement, le transfert prend beaucoup de temps (je ne l'ai pas chronométré). Existe-t-il un moyen d'accélérer cela? Dois-je utiliser un autre outil? Dois-je utiliser rsync sur ssh plutôt que d'utiliser le protocole rsync?

rsync

— Nouilles
source

Est-ce vraiment seulement des centaines? Comme dans moins de quelques milliers?

— Zoredache

Un peu plus que cela ... 475 576 pour un total de 9,3 Go

— Noodles

Cela va sucer en utilisant presque n'importe quel outil qui fonctionne au niveau du système de fichiers. Je soupçonne que si vous faisiez du profilage, vous verriez un temps considérable passé à appeler stat().

— Zoredache

Pourquoi pas -amais -r?

— kamae

13

Vous devez déterminer le goulot d'étranglement. Ce n'est pas rsync. Ce n'est probablement pas la bande passante de votre réseau. Comme l'a suggéré @Zoredache, il s'agit très probablement du grand nombre d'iops générés par tous les stat()appels. N'importe quel outil de synchronisation devra statuer les fichiers. Pendant la synchronisation, exécutez iostatpour vérifier.

Alors la question devient; comment optimiser les statistiques? Deux réponses faciles:

obtenir un sous-système de disque plus rapide (sur les deux hôtes si nécessaire) et
régler votre système de fichiers (par exemple pour le montage ext3 avec noatimeet ajoutez a dir_index).

Si, par hasard, ce n'est pas votre iops de disque qui est la limite, vous pouvez essayer de diviser l'arborescence dir en plusieurs arborescences distinctes et d'exécuter plusieurs rsyncs.

— Mark Wagner
source

1

Merci, je vais regarder dir_index et voir comment j'en suis (nous utilisons déjà noatime). Il semble que le disque io soit le goulot d'étranglement, mais nous utilisons déjà des disques SAS 15 000 en RAID 5. La prochaine étape serait le SSD, mais notre société d'hébergement ne nous donne pas encore cette option.

— Noodles

5

La compression n'est pas très utile pour les petits fichiers (par exemple, moins de 100 octets). Pour les petits fichiers, la version compressée peut parfois être encore plus grande que l'original. Essayez la rsynccommande sans le -zdrapeau.

sshest bon pour la sécurité, mais ne rendra pas le transfert plus rapide. En fait, cela rendrait le transfert plus lent en raison du besoin de chiffrement / déchiffrement.

rsyncpeut ne pas sembler rapide la première fois qu'il est exécuté car il y a beaucoup de données à transférer. Cependant, si vous prévoyez d'exécuter cette commande périodiquement, les exécutions suivantes peuvent être beaucoup plus rapides car il rsyncest judicieux de ne pas transférer les fichiers qui n'ont pas changé.

— unutbu
source

Si vous utilisez simplement le rsyncclient, il utilisera SSH en arrière-plan. Vous devez tout faire pour désactiver le chiffrement lors de l'utilisation de rsync. Voir: stackoverflow.com/a/1821574/64911

— mlissner

1

Quelle version de rsync utilisez-vous? Tout ce qui est antérieur à 3.0.0 (aux deux extrémités) n'a pas la fonctionnalité de liste de fichiers incrémentielle, ce qui accélère les transferts importants.

— devicenull
source

Utilisation de rsync 3.0.5 sur les deux serveurs.

— Noodles

1

Ajoutez -v --progressà votre ligne de commande rsync

rsync se fait en 2 étapes:

parcourir en profondeur tous les fichiers sur les deux plates-formes pour comparer leur taille et leur date de création
faire le transfert proprement dit

Si vous rsync des milliers de petits fichiers dans des répertoires imbriqués, il se peut simplement que rsync passe la plupart de ce temps à aller dans les sous-répertoires et à trouver tous les fichiers

Si vous ne passez pas de temps à naviguer, le temps peut simplement être dû à l'ajout de toutes les latences à chaque nouveau transfert de fichier.

— Alex F
source

1

Dans le cas où des systèmes de fichiers ext3 ou ext4 sont impliqués, vérifiez que la fonction dir_index est activée sur les deux! Cela a triplé le débit rsync dans mon cas.

Voir les détails dans ma réponse à: /server//a/759421/80414

— Alfonx
source