Synchronisation plus rapide d'un énorme répertoire qui n'a pas été modifié

13

Nous utilisons rsync pour sauvegarder les serveurs.

Malheureusement, le réseau de certains serveurs est lent.

Il faut jusqu'à cinq minutes pour que rsync détecte que rien n'a changé dans les énormes répertoires. Ces énormes arborescences de répertoires contiennent beaucoup de petits fichiers (environ 80k fichiers).

Je suppose que les clients rsync envoient des données pour chacun des fichiers 80k.

Comme le réseau est lent, je voudrais éviter d'envoyer 80 000 fois des informations sur chaque fichier.

Existe-t-il un moyen de dire à rsync de faire une somme de hachage d'une arborescence de sous-répertoires?

De cette façon, le client rsync n'enverrait que quelques octets pour une énorme arborescence de répertoires.

Mise à jour

Jusqu'à présent, ma stratégie est d'utiliser rsync. Mais si un outil différent convient mieux ici, je peux changer. Les deux (serveur et client) sont sous mon contrôle.

Update2

Il y a 80k fichiers dans une arborescence de répertoires . Chaque répertoire ne contient pas plus de 2 000 fichiers ou sous-répertoires

Update3

Détails sur la lenteur du réseau:

time ssh einswp 'cd attachments/200 && ls -lLR' >/tmp/list
real    0m2.645s

Taille du fichier tmp / list: 2MByte

time scp einswp:/tmp/list tmp/
real    0m2.821s

Conclusion: scp a la même vitesse (pas de surprise)

time scp einswp:tmp/100MB tmp/
real    1m24.049s

Vitesse: 1,2 Mo / s

rsync synchronization guettli
la source
1
Vous pourriez lire sur zsync. Je ne l'ai pas utilisé moi-même, mais d'après ce que j'ai lu, il pré-rend les métadonnées côté serveur et pourrait simplement accélérer les transferts dans votre cas. Cela pourrait valoir la peine d'être testé de toute façon. Au-delà de cela, la seule autre solution que je connaisse est la synchronisation en temps réel au niveau des blocs qui vient avec certaines solutions san / nas.
Aaron

Réponses:

36

Quelques points sans rapport:

80K, c'est beaucoup de fichiers.

80 000 fichiers dans un seul répertoire? Aucun système d'exploitation ou application ne gère très bien cette situation par défaut. Vous venez de remarquer ce problème avec rsync.

Vérifiez votre version rsync

Le rsync moderne gère beaucoup mieux les grands répertoires que par le passé. Assurez-vous que vous utilisez la dernière version.

Même les anciens rsync gèrent assez bien les gros répertoires sur des liens à latence élevée ... mais les fichiers de 80k ne sont pas gros ... c'est énorme!

Cela dit, l'utilisation de la mémoire de rsync est directement proportionnelle au nombre de fichiers dans une arborescence. Les grands répertoires prennent une grande quantité de RAM. La lenteur peut être due à un manque de RAM de chaque côté. Effectuez un test en regardant l'utilisation de la mémoire. Linux utilise toute la RAM restante comme cache disque, donc si vous manquez de RAM, il y a moins de cache disque. Si vous manquez de RAM et que le système commence à utiliser le swap, les performances seront vraiment mauvaises.

Assurez-vous que --checksum n'est pas utilisé

--checksum(ou -c) nécessite la lecture de chaque bloc de chaque fichier. Vous pouvez probablement vous en tirer avec le comportement par défaut de simplement lire les heures de modification (stockées dans l'inode).

Divisez le travail en petits lots.

Il y a des projets comme Gigasync qui " réduiront la charge de travail en utilisant perl pour récapituler l'arborescence des répertoires, en construisant de petites listes de fichiers à transférer avec rsync."

L'analyse du répertoire supplémentaire va représenter une grande quantité de frais généraux, mais ce sera peut-être une victoire nette.

Les valeurs par défaut du système d'exploitation ne sont pas définies pour cette situation.

Si vous utilisez Linux / FreeBSD / etc avec tous les paramètres par défaut, les performances seront terribles pour toutes vos applications. Les valeurs par défaut supposent des répertoires plus petits afin de ne pas gaspiller de RAM sur les caches surdimensionnés.

Ajustez votre système de fichiers pour mieux gérer les grands répertoires: les grandes tailles de dossiers ralentissent-elles les performances d'E / S?

Regardez le "cache namei"

Les systèmes d'exploitation de type BSD ont un cache qui accélère la recherche d'un nom vers l'inode (le cache "namei"). Il y a un cache namei pour chaque répertoire. S'il est trop petit, c'est un obstacle plus qu'une optimisation. Étant donné que rsync effectue un lstat () sur chaque fichier, l'inode est accessible pour chacun des fichiers de 80 Ko. Cela pourrait faire exploser votre cache. Recherchez comment régler les performances du répertoire de fichiers sur votre système.

Envisagez un système de fichiers différent

XFS a été conçu pour gérer des répertoires plus volumineux. Voir Filesystem grand nombre de fichiers dans un seul répertoire

Peut-être que 5 minutes est le mieux que vous puissiez faire.

Envisagez de calculer le nombre de blocs de disque en cours de lecture et calculez la vitesse à laquelle vous devez vous attendre à ce que le matériel puisse lire autant de blocs.

Peut-être que vos attentes sont trop élevées. Considérez combien de blocs de disque doivent être lus pour effectuer une rsync sans fichiers modifiés: chaque serveur devra lire le répertoire et lire un inode par fichier. Supposons que rien ne soit mis en cache car, eh bien, 80k fichiers ont probablement fait exploser votre cache. Disons que c'est 80k blocs pour garder les mathématiques simples. Cela représente environ 40 millions de données, qui devraient être lisibles en quelques secondes. Cependant, s'il doit y avoir une recherche de disque entre chaque bloc, cela pourrait prendre beaucoup plus de temps.

Vous devrez donc lire environ 80 000 blocs de disques. À quelle vitesse votre disque dur peut-il faire cela? Étant donné qu'il s'agit d'E / S aléatoires, pas d'une longue lecture linéaire, 5 minutes pourraient être assez excellentes. C'est 1 / (80000/600), ou un disque lu toutes les 7,5 ms. Est-ce rapide ou lent pour votre disque dur? Cela dépend du modèle.

Référence par rapport à quelque chose de similaire

Une autre façon d'y penser est la suivante. Si aucun fichier n'a changé, ls -Llreffectue la même quantité d'activité sur le disque mais ne lit jamais les données de fichier (uniquement les métadonnées). Le temps ls -Llrnécessaire à l'exécution est votre limite supérieure.

  • Rsync (sans modification de fichiers) est-il beaucoup plus lent que ls -Llr? Ensuite, les options que vous utilisez pour rsync peuvent être améliorées. Peut -c- être est activé ou un autre indicateur qui lit plus que des répertoires et des métadonnées (données d'inode).

  • Rsync (sans modification des fichiers) est-il presque aussi rapide que ls -Llr? Ensuite, vous avez réglé le mieux possible rsync. Vous devez régler le système d'exploitation, ajouter de la RAM, obtenir des disques plus rapides, modifier les systèmes de fichiers, etc.

Parlez à vos développeurs

Les fichiers 80k sont juste une mauvaise conception. Très peu de systèmes de fichiers et d'outils système gèrent très bien ces gros répertoires. Si les noms de fichiers sont abcdefg.txt, pensez à les stocker dans abdc / abcdefg.txt (notez la répétition). Cela divise les répertoires en plus petits, mais ne nécessite pas une énorme modification du code.

Pensez également à utiliser une base de données. Si vous avez 80k fichiers dans un répertoire, vos développeurs peuvent peut-être contourner le fait que ce qu'ils veulent vraiment, c'est une base de données. MariaDB ou MySQL ou PostgreSQL serait une bien meilleure option pour stocker de grandes quantités de données.

Hé, qu'est-ce qui ne va pas avec 5 minutes?

Enfin, 5 minutes sont-elles vraiment si mauvaises? Si vous exécutez cette sauvegarde une fois par jour, 5 minutes, ce n'est pas beaucoup de temps. Oui, j'aime la vitesse. Cependant, si 5 minutes sont "assez bonnes" pour vos clients, elles sont suffisantes pour vous. Si vous n'avez pas de contrat de niveau de service écrit, que diriez-vous d'une discussion informelle avec vos utilisateurs pour savoir à quelle vitesse ils s'attendent à ce que les sauvegardes prennent.

Je suppose que vous n'avez pas posé cette question s'il n'était pas nécessaire d'améliorer les performances. Cependant, si vos clients sont satisfaits de 5 minutes, déclarez la victoire et passez à d'autres projets qui nécessitent vos efforts.

Mise à jour: Après quelques discussions, nous avons déterminé que le goulot d'étranglement est le réseau. Je vais recommander 2 choses avant d'abandonner :-).

  • Essayez d'extraire plus de bande passante du tuyau avec la compression. Cependant, la compression nécessite plus de CPU, donc si votre CPU est surchargé, cela peut aggraver les performances. Essayez rsync avec et sans -z, et configurez votre ssh avec et sans compression. Minutez les 4 combinaisons pour voir si l'une d'entre elles est nettement meilleure que les autres.
  • Regardez le trafic réseau pour voir s'il y a des pauses. S'il y a des pauses, vous pouvez trouver la cause et les optimiser. Si rsync envoie toujours, alors vous êtes vraiment à votre limite. Vos choix sont:
    • un réseau plus rapide
    • autre chose que rsync
    • rapprochez la source et la destination. Si vous ne pouvez pas faire cela, pouvez-vous rsync vers une machine locale puis rsync vers la destination réelle? Cela peut présenter des avantages si le système doit être arrêté lors de la synchronisation initiale.
TomOnTime
la source
80K, c'est beaucoup de fichiers.: Il y a 80k fichiers dans une arborescence de répertoires . Chaque répertoire n'a pas plus de 2k fichiers / sous-répertoires.
guettli
Vérifiez votre version rsync: terminé, assurez-vous que --checksum n'est pas utilisé: terminé. Divisez le travail en petits lots: Merci, je vais jeter un œil à gigasync. Les paramètres par défaut du système d'exploitation ne sont pas définis pour cette situation: terminé (le goulot d'étranglement est le réseau et non le système d'exploitation). Regardez le "cache namei": c'est fait (c'est net, pas OS). Considérez un système de fichiers différent: encore une fois net, pas OS. Peut-être que 5 minutes est le mieux que vous puissiez faire. Je pense que cela pourrait être beaucoup plus rapide. Parlez à vos développeurs (utilisez DB): Ce serait un énorme changement. Peut-être qu'un système de fichiers avec un meilleur support de sauvegarde le résoudrait.
guettli
2k fichiers par répertoire, c'est beaucoup mieux. Merci pour la mise à jour. Vous n'aviez pas mentionné que le réseau était lent. Est-ce une faible bande passante, une latence élevée ou les deux? rsync fonctionne généralement bien sur les liaisons à latence élevée (il a été développé par quelqu'un travaillant sur son doctorat en Australie tout en traitant avec des ordinateurs aux États-Unis). Essayez de faire "ls -lLR" sur ssh et chronométrez le temps nécessaire pour transmettre le résultat. msgstr "heure ssh remotehost 'cd / dest && ls -lLR'> / tmp / list". Assurez-vous que la liste / tmp / est créée sur l'hôte local.
TomOnTime
oui le réseau est lent. C'est dommage.
guettli
C'est lent? Si vous utilisez "scp" pour copier un fichier de 100M, combien de temps cela prend-il? De plus, quelle est la sortie de "time ssh remotehost 'cd / dest && ls -lLR'> / tmp / list"?
TomOnTime
2

Non, ce n'est pas possible avec rsync et ce serait tout à fait inefficace à un autre égard:

Normalement, rsyncne compare que les dates de modification des fichiers et les tailles de fichiers. Votre approche l'obligerait à lire et à additionner le contenu de tous les fichiers deux fois (sur le système local et distant) pour trouver les répertoires modifiés.

Sven
la source
1
AFAIK rsync vérifie le temps et la taille. Si les deux correspondent, le fichier n'est pas transféré à nouveau (au moins dans les paramètres par défaut). Il suffirait d'envoyer le hachage des tuples (nom de fichier, taille, mtime). Il n'est pas nécessaire de contrôler le contenu.
guettli
Oui, vous avez raison, mais de toute façon, rsyncne le fait pas.
Sven
2

Pour la synchronisation d'un grand nombre de fichiers (où peu de choses ont changé), il convient également de définir noatimeles partitions source et de destination. Cela permet d'économiser les temps d'accès en écriture sur le disque pour chaque fichier inchangé.

Andy Beverley
la source
Oui, l'option noatime est logique. Nous l'utilisons depuis plusieurs années. Je suppose qu'une alternative à rsync est nécessaire.
guettli
2

Vous pouvez également essayer lsyncd, qui ne rsync que lorsque des modifications sont détectées sur le système de fichiers et uniquement les sous-répertoires modifiés. Je l'ai utilisé pour des répertoires contenant jusqu'à deux millions de fichiers sur un serveur décent.

Juanga Covas
la source