Comment accélérer rsync / tar de Maildir volumineux?

7

J'ai un très grand Maildir que je copie sur une nouvelle machine (sur 100BASE-T) avec rsync. La progression est lente. TRÈS LENT. Comme 1 Mo / s lent. Je pense que c'est parce que beaucoup de petits fichiers sont lus dans un ordre qui est essentiellement aléatoire par rapport à l'emplacement où les blocs sont stockés sur le disque, provoquant une tempête de recherche massive. J'obtiens des résultats similaires en essayant de trier le répertoire. Existe-t-il un moyen d’obtenir que rsync / tar soit lu dans l’ordre des blocs de disque ou de résoudre ce problème autrement?

Edit: J'ai essayé tar cf / dev / zero Maildir / et sur l'ancien système, cela prenait 30 minutes! Sur le nouveau système, lorsque le rsync est finalement terminé, le même test a duré 18 minutes. Le vidage du même répertoire sur l'ancien système a duré 8 minutes, et sur le nouveau système, le vidage de -0f / dev / zero -b 1024 / home / psusi / Maildir / s'est terminé en 30 secondes seulement.

    
posée psusi 10.03.2011 - 21:55
la source

3 réponses

7

J'ai fini par écrire un petit script python pour calculer la corrélation entre les noms de répertoire et les inodes, les inodes et les blocs de données, et les noms de répertoires des blocs de données. Il s'avère que ext4 a tendance à avoir une corrélation plutôt médiocre entre l'ordre dans lequel les noms de fichiers apparaissent dans le répertoire et où ils sont stockés sur le disque. Après en avoir discuté dans la liste de diffusion ext4, il s’avère qu’il s’agit du résultat des index de répertoires hachés utilisés pour accélérer les recherches dans les grands répertoires. Les noms sont stockés dans l'ordre de hachage, ce qui brouille efficacement leur ordre par rapport à toute autre chose.

Il me semble, et au moins un autre commentateur, qu’il s’agit d’une lacune dans les fs à corriger. Ted Ts'o (le responsable externe) pense que ce serait trop difficile à faire dans le fs, et que de bons outils (comme rsync et tar) devraient avoir une option pour trier le répertoire par numéro d'inode avant de lire les fichiers. p>

Il semble donc que les demandes d’amélioration des fonctionnalités doivent être classées pour rsync et tar.

    
réponse donnée psusi 23.03.2011 - 19:18
la source
2

Quelques points à considérer:

  • De combien de fichiers parlons-nous? find /path/to/your/maildir/ | wc -l devrait vous donner une indication approximative. Des centaines de milliers de personnes devraient être d'accord. Des centaines de millions peuvent suggérer que vous devez tailler, archiver et généralement nettoyer.

  • Le disque est-il lent? Il existe de nombreux benchmarks, comme le bonnie++ complet jusqu'au benchmark rapide et simple de Disk Utility. Exécuter un et voir si vous souffrez.

    • Cela peut poser des problèmes matériels - remplacez-le par quelque chose de plus rapide
    • Problèmes liés au système de fichiers - utilisez-vous quelque chose de très lent en lecture aléatoire haute IOPS?

Mais finalement, tar sonne puis transfère devrait vous offrir le meilleur débit global au prix de la nécessité de configurer le transfert une fois que vous avez généré le tar.

    
réponse donnée Oli 10.03.2011 - 22:03
la source
1

Essayez de désactiver le suivi d’atime ou d’utiliser un temps relatif sur la nouvelle partition de disque. Cela limitera les frais généraux. Le passage d'un système de fichiers non journalisé tel que ext2 à un système de fichiers journalisé tel qu'ext3 ou ext4 aura des répercussions sur les performances

Lorsque j'ai déménagé Maildirs, j'ai effectué une rsync préparatoire pour mettre en place tous les répertoires à l'avance. Ensuite, il n'y avait que des mises à jour à faire.

Lorsque vous êtes prêt à faire le vrai geste, vous pouvez vous assurer que les répertoires sont stables.

  • placez le démon SMTP en mode file d'attente uniquement,
  • désactiver la file d'attente s'exécute par le démon SMTP, et
  • désactiver l'accès par l'utilisateur.

Réactiver une fois le déplacement du fichier terminé.

EDIT: Je pense que vous avez identifié le problème. Tar et rsync vont parcourir les répertoires. En raison des modifications de fichiers normales dans Maildir, les fichiers de chaque répertoire seront dispersés sur le disque. Un outil comme dump lirait la partition en ordre de bloc, mais répliquerait le problème sur la nouvelle partition. Une seconde synchronisation devrait être beaucoup plus rapide que la seconde.

    
réponse donnée BillThor 11.03.2011 - 05:10
la source

Lire d'autres questions sur les étiquettes