web-dev-qa-db-fra.com

Pourquoi mes systèmes de fichiers XFS consomment-ils soudainement plus d'espace et pleins de fichiers épars?

J'ai exécuté systèmes de fichiers XFS en tant que partitions de données/croissance pendant près de 10 ans sur divers serveurs Linux.

J'ai remarqué un phénomène étrange avec les serveurs CentOS/RHEL récents exécutant la version 6.2+.

L'utilisation stable du système de fichiers est devenue très variable suite au passage à la nouvelle version du système d'exploitation d'EL6.0 et EL6.1. Les systèmes initialement installés avec EL6.2 + présentent le même comportement; montrant les fluctuations sauvages de l'utilisation du disque sur les partitions XFS (voir la ligne bleue dans le graphique ci-dessous).

Avant et après. La mise à niveau de 6.1 vers 6.2 s'est produite samedi.xfs graph

Le graphique d'utilisation du disque du dernier trimestre du même système, montrant les fluctuations au cours de la dernière semaine.enter image description here

J'ai commencé à vérifier les systèmes de fichiers pour les fichiers volumineux et les processus d'emballement (fichiers journaux, peut-être?). J'ai découvert que mes fichiers les plus volumineux signalaient des valeurs différentes de du et ls. Exécution de du avec et sans le --apparent-size switch illustre la différence.

# du -skh SOD0005.TXT
29G     SOD0005.TXT

# du -skh --apparent-size SOD0005.TXT
21G     SOD0005.TXT

Une vérification rapide à l'aide de l'utilitaire ncd sur l'ensemble du système de fichiers a donné:

Total disk usage: 436.8GiB  Apparent size: 365.2GiB  Items: 863258

Le système de fichiers est plein de fichiers épars , avec près de 70 Go d'espace perdu par rapport à la version précédente du système d'exploitation/noyau!

J'ai parcouru Red Hat Bugzilla et changé les journaux pour voir s'il y avait des rapports du même comportement ou de nouvelles annonces concernant XFS.

Nada.

Je suis passé de la version du noyau 2.6.32-131.17.1.el6 à 2.6.32-220.23.1. el6 pendant la mise à niveau; aucun changement de numéro de version mineur.

J'ai vérifié la fragmentation des fichiers avec l'outil filefrag. Certains des plus gros fichiers de la partition XFS avaient des milliers d'extensions. Exécution de la défragmentation en ligne avec xfs_fsr -v pendant une période d'activité lente a permis de réduire temporairement l'utilisation du disque (voir mercredi dans le premier graphique ci-dessus). Cependant, l'utilisation a explosé dès que l'activité du système a repris.

Que se passe-t-il ici?

linuxcentosredhatfilesystemsxfs
64
ewwhite

J'ai retracé ce problème à une discussion sur une validation de la arbre source XFS de décembre 2010. Le correctif a été introduit dans le noyau 2.6.38 (et évidemment, plus tard rétroporté dans certains noyaux de distribution Linux populaires).

Les fluctuations observées dans l'utilisation du disque sont le résultat d'une nouvelle fonctionnalité; XFS Dynamic Speculative EOF Preallocation .

Il s'agit d'une mesure visant à réduire la fragmentation des fichiers lors de l'écriture en streaming en allouant de manière spéculative de l'espace à mesure que la taille des fichiers augmente. La quantité d'espace préallouée par fichier est dynamique et est principalement fonction de l'espace libre disponible sur le système de fichiers (pour éviter de manquer complètement d'espace).

Il suit ce calendrier:

freespace       max prealloc size
  >5%             full extent (8GB)
  4-5%             2GB (8GB >> 2)
  3-4%             1GB (8GB >> 3)
  2-3%           512MB (8GB >> 4)
  1-2%           256MB (8GB >> 5)
  <1%            128MB (8GB >> 6)

Ceci est un ajout intéressant au système de fichiers car il peut aider avec certains des fichiers massivement fragmentés que je traite.

L'espace supplémentaire peut être récupéré temporairement en libérant la pagecache, les dentiers et les inodes avec:

sync; echo 3 > /proc/sys/vm/drop_caches

La fonctionnalité peut être entièrement désactivée en définissant une valeur allocsize lors du montage du système de fichiers. La valeur par défaut pour XFS est allocsize=64k.

L'impact de ce changement sera probablement ressenti par les systèmes de surveillance/seuillage (c'est ainsi que je l'ai détecté), mais a également affecté systèmes de base de données et pourrait entraîner des résultats imprévisibles ou indésirables pour les machines virtuelles à allocation dynamique et des baies de stockage (elles utiliseront plus d'espace que prévu).

Dans l'ensemble, cela m'a pris au dépourvu car il n'y avait aucune annonce claire du changement de système de fichiers au niveau de la distribution ou même dans la surveillance de la liste de diffusion XFS .

Modifier :
Les performances sur les volumes XFS avec cette fonctionnalité sont considérablement améliorées. Je constate une fragmentation <1% cohérente sur des volumes qui affichaient auparavant jusqu'à 50% de fragmentation. Les performances d'écriture sont en hausse à l'échelle mondiale!

Statistiques du même ensemble de données, comparant l'héritage XFS à la version dans EL6.3.

Vieux:

# xfs_db -r -c frag /dev/cciss/c0d0p9
actual 1874760, ideal 1256876, fragmentation factor 32.96%

Nouveau:

# xfs_db -r -c frag /dev/sdb1
actual 1201423, ideal 1190967, fragmentation factor 0.87%
78
ewwhite