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.