Avant de modifier les paramètres XFS, vous devez comprendre pourquoi les paramètres XFS par défaut causent des problèmes de performance. Cela implique de comprendre ce que fait votre application et de quelle manière le système de fichiers réagit à ces opérations.
Les problèmes de performance pouvant être observés qui peuvent être corrigés ou réduits par le biais de réglages sont généralement causés par la fragmentation du fichier ou par des conflits de ressources dans le système de fichiers. Il existe plusieurs manières de répondre à ces problèmes et dans certains cas, la correction du problème requerra que ce soit l'application, plutôt que la configuration du système de fichiers, qui soit modifiée.
Si vous n'avez pas effectué ce processus précédemment, il est recommandé de vous renseigner auprès de votre ingénieur d'assistance Red Hat local.
Optimisation pour un grand nombre de fichiers
XFS impose une limite arbitraire sur le nombre de fichiers qu'un système de fichiers peut contenir. En général, cette limite est suffisamment élevée pour ne jamais être atteinte. Si vous savez à l'avance que la limite par défaut sera insuffisante, vous pouvez augmenter le pourcentage d'espace du système de fichiers autorisé aux inodes avec la commande mkfs.xfs. Si vous atteignez la limite de fichiers après la création du système de fichiers (habituellement indiqué par des erreurs ENOSPC lors d'une tentative de création de fichier ou de répertoire alors qu'il existe de l'espace disponible), vous pouvez ajuster la limite avec la commande xfs_growfs.
Optimisation pour un grand nombre de fichiers dans un seul répertoire
La taille de bloc d'un répertoire est fixée pour la durée de vie d'un système de fichiers et ne peut pas être modifiée, sauf lors du formatage initial avec mkfs. Le bloc de répertoire minimum est la taille de bloc du système de fichiers, qui est par défaut MAX (4 Ko, taille de bloc du système de fichiers). En générale, il n'y a pas de raison de réduire la taille de bloc du répertoire.
Comme la structure de répertoire est basée sur un arbre B, modifier la taille de bloc affecte la quantité d'informations sur le répertoire qui peuvent être récupérées ou modifiées par entrée ou sortie (E/S) physique. Plus la taille d'un répertoire augmente, plus les entrées et sorties requises par chaque opération sur une taille de bloc donnée seront nombreuses.
Cependant, lorsque des tailles de blocs plus importantes sont en cours d'utilisation, plus de CPU sont consommés par chaque opération de modification comparé à la même opération sur un système de fichiers avec une plus petite taille de bloc de répertoire. Cela signifie que pour les répertoires de plus petite taille, des blocs de répertoire de grande taille résulteront en de plus mauvaises performances de modification. Lorsque le répertoire atteint une taille avec laquelle les entrées et sorties (E/S) constituent le facteur limitant la performance, les blocs de répertoire de plus grande taille fonctionneront mieux.
La configuration par défaut d'un bloc de système de fichiers d'une taille de 4 Ko et d'un bloc de répertoire d'une taille de 4 Ko est meilleure pour les répertoires avec 1 à 2 millions d'entrées avec une longueur de nom de 20 à 40 octets par entrée. Si votre système de fichiers requiert davantage d'entrées, les blocs de répertoire de plus grande taille auront tendance à mieux fonctionner - une taille de bloc de 16 Ko est plus appropriée pour des systèmes de fichiers avec 1 à 10 millions d'entrées et une taille de bloc de 64 Ko sera plus appropriée pour des systèmes de fichiers avec plus de 10 millions d'entrées de répertoires.
Si la charge de travail utilise plus de recherches aléatoires de répertoires que de modifications (c'est-à-dire si les lectures de répertoires sont bien plus communes ou importantes que les écritures de répertoires), alors les limites ci-dessus pour augmenter la taille des blocs sont d'environ un ordre de magnitude plus faible.
Optimisation pour la simultanéité
Contrairement aux autres systèmes de fichiers, XFS peut effectuer de nombreux types d'opérations d'allocation et de dé-allocation simultanément, à condition que les opérations se produisent sur des objets non-partagés. Les allocations et dé-allocations d'extensions peuvent se produire en même temps à condition que les opérations simultanées se produisent dans différents groupes d'allocation. De manière similaire, les allocations ou dé-allocations d'inodes peuvent se produire en même temps à condition que les opérations simultanées affectent différents groupes d'allocation.
Le nombre de groupes d'allocation devient important lorsque des machines avec un compte de CPU élevé et des applications à multiples threads qui tentent d'effectuer des opérations simultanément sont utilisées. Si seuls quatre groupes d'allocation existent, alors des opérations de métadonnées prolongées et parallèles n'évolueront pas plus que ces quatre CPU (qui est la limite de simultanéité fournie par le système). Pour de petits systèmes de fichiers, assurez-vous que le nombre de groupes d'allocation est pris en charge par la simultanéité fournie par le système. Pour des systèmes de fichiers de grande taille (plusieurs dizaines de téraoctets et au-delà), les options de formatage par défaut créent généralement suffisamment de groupes d'allocation pour éviter de limiter la simultanéité.
Les applications doivent être conscientes des points de contention uniques afin d'utiliser le parallélisme inhérent à la structure du système de fichiers XFS. Il n'est pas possible de modifier un répertoire simultanément. Ainsi, des applications créant et supprimant de nombreux fichiers éviteront de stocker tous les fichiers dans un répertoire unique. Chaque répertoire créé est placé dans un groupe d'allocation différent. Ainsi, des techniques telles que le hachage de fichiers sur de multiples sous-répertoires fournissent un schéma de stockage plus modulable comparé à l'utilisation d'un seul répertoire de grande taille.
Optimisation pour des applications utilisant des attributs étendus
XFS peut stocker des attributs de petite taille directement dans l'inode si l'espace est disponible dans l'inode. Si l'attribut peut être intégré dans l'inode, alors il peut être récupéré et modifié sans devoir faire recours à des E/S supplémentaires pour récupérer des blocs d'attributs séparés. Le différentiel de performance entre les attributs « en ligne » et « hors-ligne » peut aisément être d'un ordre de magnitude plus lent pour les attributs « hors-ligne ».
Pour la taille d'inode par défaut de 256 octets, environ 100 octets de l'espace attribué est disponible selon le nombre de pointeurs d'extensions de données aussi stockés dans l'inode. La taille d'inode par défaut n'est vraiment utile que pour le stockage de quelques petits attributs.
Augmenter la taille d'inode lors de la commande mkfs peut augmenter la quantité d'espace disponible pour le stockage des attributs en ligne. Un inode d'une taille de 512 octets augmente l'espace disponible pour les attributs jusqu'à environ 350 octets ; un inode de 2 Ko possède environ 1900 octets d'espace disponible.
Il existe cependant une limite à la taille des attributs individuels pouvant être stockés en ligne. La limite de taille maximale est de 254 octets pour le nom de l'attribut et la valeur (c'est-à-dire un attribut avec une longueur de nom de 254 octets et une longueur de valeur de 254 octets restera en ligne). Le dépassement de ces limites force les attributs hors-ligne, même s'il y avait suffisamment d'espace pour stocker tous les attributs dans l'inode.
Optimisation pour les modifications de métadonnées prolongées
La taille du journal est le facteur principal déterminant le niveau réalisable de modifications prolongées de métadonnées. Le périphérique journal est circulaire et avant que les données de la queue puisse être écrasées, toutes les modifications dans le journal doivent être écrites sur les emplacements réels sur le disque. Cela implique un effort significatif de recherche pour réécrire toutes les métadonnées modifiées.
Un périphérique journal de petite taille résultera en de très fréquentes réécritures de métadonnées. Le journal poussera constamment sa queue pour libérer de l'espace et les métadonnées fréquemment modifiées seront fréquemment écrites sur disque, ralentissant ainsi les opérations.
L'augmentation de la taille du journal augment la période de temps entre les événements push sur la queue. Cela permet une meilleure agrégation des métadonnées modifiées, résultant en des meilleurs schémas de réécriture de métadonnées et des réécritures de métadonnées fréquemment modifiées moindres. Le compromis est que des journaux de plus grande taille nécessiteront plus de mémoire pour surveiller toutes les modifications arriérées en mémoire.
Si vous possédez une machine avec une mémoire limitée, alors des journaux de grande taille ne seront pas bénéfiques puisque les contraintes de mémoire entraîneront des réécritures de métadonnées longtemps avant que les bénéfices d'un journal de grande taille puisse être réalisé. Dans ces cas, des journaux de plus petite taille fourniront plus souvent une meilleure performance car des réécritures de métadonnées du journal manquant d'espace sont plus efficaces que les réécritures entraînées par la réclamation de mémoire.
Vous deviez toujours tenter d'aligner le journal sur l'unité en bande sous-jacente du périphérique qui contient le système de fichiers. mkfs effectue cela par défaut pour les périphériques MD et DM, mais pour le RAID logiciel, il se peut qu'il faille le spécifier. Paramétrer ceci correctement prévient toute possibilité d'E/S de journal provoquant des E/S non-alignées et des opérations de lecture-modification-écriture conséquentes lors de l'écriture de modifications sur disque.
Les opérations du journal peuvent être améliorées en modifiant les options de montage. L'augmentation de la taille des mémoires tampon de journaux situés dans la mémoire (logbsize) augmente la vitesse à laquelle les modifications peuvent être écrites sur le journal. La taille de la mémoire tampon de journal par défaut est MAX (32 Ko, unité de bande de journal) et la taille maximale est de 256 Ko. En général, une valeur plus importante se traduit par une performance plus rapide. Cependant, sous de lourdes charges de travail fsync, des mémoires tampon de journaux de petite taille sont visiblement plus rapides que des mémoires tampon de grande taille avec un alignement d'unité de bande de grande taille.
L'option de montage delaylog améliore aussi les performances des modifications prolongées de métadonnées en réduisant le nombre de modifications apportées au journal. Ceci est réalisé en agrégeant des modifications individuelles en mémoire avant de les écrire sur le journal : les métadonnées fréquemment modifiées sont écrites sur le journal de manière périodique plutôt qu'à chaque fois qu'une modification est effectuée. Cette option augmente l'utilisation par la mémoire du suivi des métadonnées modifiées et augmente le nombre d'opérations potentiellement perdues lorsqu'un incident se produit, mais elle peut améliorer la vitesse et l'évolutivité des modifications de métadonnées par un ordre de magnitude ou plus. L'utilisation de cette option ne réduit pas l'intégrité des données ou métadonnées lorsque fsync, fdatasync ou sync sont utilisés pour s'assurer que les données ou métadonnées soient bien écrites sur le disque.
Red Hat Summit
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}