1 votes

sporadiquement, rsync est exceptionnellement long

Nous effectuons des sauvegardes avec rsync de cette manière :

rsync -axH --inplace --delete --delete-excluded \
--exclude-from=excludes --stats \
--link-dest="${previous?}" "${source?}"/ "${dest?}"/"${stamp?}"

$previous pointe vers la sauvegarde précédente, de sorte que les fichiers inchangés seront créés à l'aide de liens hypertextes. Le système de fichiers de destination $dest se trouve sur un disque dur USB externe qui ne contient rien d'autre que la collection de sauvegardes.

Cette méthode est étonnamment rapide dans la plupart des cas. Sur le système de test, chaque sauvegarde est d'environ 200 Go et contient de gros répertoires. Pourtant, l'ensemble du rsync (à condition que peu de choses aient été modifiées depuis la dernière exécution) ne prend qu'une minute environ.

Cependant, dans de rares cas, peut-être tous les 100 exécutions en moyenne, cela prend beaucoup de temps, environ 20 minutes ou plus. Les statistiques de rsync ne montrent rien d'anormal. Le système hôte ne montre aucune activité inhabituelle pendant ces exécutions. Rien d'intéressant dans le syslog.

Il semble que ce soit pire sur certains systèmes de fichiers (pour $dest) que sur d'autres. Les chiffres ci-dessus concernent EXT4. Sur JFS par exemple, les exécutions normales prennent environ 3 minutes et les exécutions exceptionnelles sont moins graves, mais restent un problème pour nous.

Un coup d'œil à la sortie de débogage de rsync révèle que pendant les longues exécutions, certains (gros) fichiers ne sont pas à jour, bien qu'ils n'aient pas été modifiés sur l'expéditeur. Aucun lien dur n'est créé pour ces fichiers, comme le montre leur inode. Mais les statistiques de rsync ne montrent pas plus d'octets transférés que d'habitude, et d'après l'observation des voyants d'activité du disque dur, seul le lecteur de destination fonctionne dans ces cas. Ces fichiers sont-ils copiés sur le disque de destination d'un répertoire à l'autre ? Il s'agit non seulement d'un problème de performance, mais aussi d'une consommation d'espace inutile.

Au cas où cela aurait de l'importance : juste avant la sauvegarde, la plus ancienne des sauvegardes existantes est supprimée à l'aide de la fonction :

rsync -a --delete empty/ "${dest?}"/"${old?}"

où "empty" est un répertoire vide. Cette méthode est beaucoup plus rapide que 'rm -fr'.

Quelqu'un pourrait-il proposer des explications possibles et peut-être un remède ?

Utilisation de la version 3.1.0 du protocole rsync version 31.

2voto

Lothar Points 99

Réponse courte : le coupable était la façon dont nous supprimions les anciens répertoires de sauvegarde, à savoir en rsynchronisant un répertoire vide. Nous utilisons maintenant :

find "${old?}" -delete

Cette méthode est également rapide et permet d'éviter le problème.

Réponse plus longue : en fait, les séries qui ont duré exceptionnellement longtemps se sont produites de manière absolument déterministe. Nous conservons toujours un nombre, disons n, de sauvegardes et supprimons la plus ancienne avant d'en effectuer une nouvelle. Chaque (n+1)ème sauvegarde a pris beaucoup de temps. Il semble qu'en supprimant une ancienne sauvegarde avec rsync, une partie de celle-ci est en quelque sorte invalidée pour l'opération --link-dest, de sorte que certains fichiers ne sont pas liés en dur mais copiés (apparemment copiés à partir du système de fichiers de destination lui-même). Cette procédure de copie démarre une nouvelle "période", qui se termine lorsque la première sauvegarde est supprimée, ce qui se produit après n exécutions. Ceci est très probablement dû à un bogue dans rsync ou dans le noyau, mais je n'irai pas plus loin dans mes recherches.

SistemesEz.com

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.

Powered by:

X