Groupes d'allocation XFS : tirer le meilleur parti des performances sur les systèmes NVMe

XFS NVMe ne révèle tout son potentiel que lorsque j'adapte systématiquement les groupes d'allocation, la taille des blocs, les options de montage et le planificateur d'E/S aux caractéristiques des SSD NVMe modernes. Cet article explique concrètement comment je planifie, formate et exploite un système de fichiers XFS sur NVMe afin que le parallélisme des groupes d’allocation (AG), l’optimisation du journal (log tuning) et la profondeur de la file d’attente matérielle (hardware queue depth) garantissent un débit mesurable et une faible latence.

Points centraux

• AG-Design: Choisir un nombre suffisant de groupes d'allocation pour assurer le parallélisme, sans pour autant entraîner une surcharge excessive du processeur.
• Taille du bloc: Associer les blocs du système de fichiers à des secteurs physiques de 4 Ko afin d'éviter les accès multiples.
• Réglage du support: combiner de manière ciblée les paramètres noatime, allocsize et logbufs/logbsize au lieu d'utiliser les valeurs par défaut.
• planificateur: Tester et définir „ none “ ou „ mq-deadline “ en fonction des objectifs de latence.
• Charges de travail: Configurer la base de données, le streaming et AI-Scratch avec un nombre d'AG adapté et le readahead.

Pourquoi les groupes d'allocation accélèrent-ils le NVMe ?

Les groupes d'allocation séparent les blocs libres, les inodes et les arbres B+ en zones indépendantes les unes des autres, ce qui permet à plusieurs threads de fonctionner simultanément et Verrouiller interviennent plus rarement. C’est précisément cette répartition qui convient au NVMe, qui traite les requêtes simultanément grâce à de nombreuses files d’attente et à un parallélisme poussé, réduisant ainsi les conflits de blocs. Dans la pratique, je traduis le parallélisme matériel par un nombre suffisant de tâches permettant des allocations parallèles et des mises à jour rapides des métadonnées, ce qui lisse les pics de latence. Un Comparaison des performances L'analyse des systèmes de fichiers montre souvent comment XFS s'adapte aux accès parallèles, tandis que les charges séquentielles continuent de fonctionner de manière fiable. Il est toutefois essentiel de trouver le juste équilibre : un nombre trop faible de groupes d'allocations (AG) limite les allocations parallèles, tandis qu'un nombre trop élevé entraîne une perte de performances notable. temps CPU.

Déterminer le nombre et la taille des groupes de travail

Lors de la configuration, je définis délibérément le nombre d'AG, généralement compris entre quelques dizaines et 64 à 128 AG par téraoctet, afin d'obtenir un niveau de parallélisme suffisant sans alourdir excessivement la charge administrative et de Parallélisme exploiter pleinement. Avec mkfs.xfs -f -d agcount=64 /dev/nvme0n1 je définis explicitement la répartition ; via -d taille= Il est également possible de régler la taille des AG. Pour les charges de travail comportant de nombreux petits fichiers, j’opte plutôt pour un nombre élevé d’AG ; pour les grands flux séquentiels, j’en utilise un peu moins afin de maîtriser la charge du processeur. J’évite les valeurs extrêmes, car un grand nombre de très petits AG génère beaucoup de travail de gestion lors du remplissage du système de fichiers. L’essentiel reste de s’orienter en fonction de la capacité, de la mémoire vive (RAM) disponible et des caractéristiques d’E/S typiques, afin que les allocations soient réparties de manière homogène sur ATELIERS saupoudrer.

Adapter correctement la taille des blocs au matériel

De nombreux SSD NVMe fonctionnent en interne avec des secteurs de 4 Ko, même s'ils proposent 512 octets en externe ; c'est pourquoi j'aligne la taille de bloc du système de fichiers sur 4 096 octets, ce qui permet de réduire les cycles internes de lecture-modification-écriture pour Accès en écriture. Pour la mise en forme, j'utilise par exemple mkfs.xfs -f -b size=4096 /dev/nvme0n1, lorsque la taille physique des secteurs est de 4 Ko. Un système de fichiers mal aligné génère des E/S supplémentaires inutiles, ce qui ralentit sensiblement le système, notamment lors de petites écritures aléatoires. Une taille de bloc adaptée rend les accès plus réguliers, lisse la latence et offre de meilleurs IOPS pour les requêtes courtes. Dans certains cas particuliers impliquant des tâches séquentielles très volumineuses, je combine des blocs de 4 Ko avec une lecture anticipée plus importante, afin que la Débit augmente.

Options de montage pour la charge NVMe

Même sans optimisation, XFS fonctionne déjà rapidement, mais des options de montage ciblées permettent d'exploiter davantage son potentiel et d'éviter des mises à jour inutiles des métadonnées lors de Leselast. J'active noatime,nodiratime, en fonction de la charge de travail, définissez une valeur plus élevée allocsize (par exemple 64 Mo) et augmente la taille de la mémoire tampon du journal avec logbufs=8,logbsize=256k pour un débit de métadonnées plus élevé. Au lieu de discard Au Mount, je guide fstrim périodiquement, afin que les commandes TRIM s'exécutent par lots. Voici un exemple de ligne dans /etc/fstab ressemble à ceci : /dev/nvme0n1 /data xfs noatime,nodiratime,allocsize=64m,logbufs=8,logbsize=256k 0 0. Le tableau suivant répertorie les options courantes en fonction de leur effet et de leur utilisation typique, afin que je puisse prendre des décisions plus rapidement et que la Configuration documenter.

Option	Effet	Quand utiliser
noatime,nodiratime	Réduit les écritures de métadonnées lors des accès	Nombreuses lectures, charges de travail Web et d'analyse
allocsize=64 Mo	Regroupe les allocations, réduit la fragmentation	Flux d'écriture séquentiels importants
logbufs=8	Davantage de tampons de journalisation parallèles pour les métadonnées	Charge de transactions, nombreuses petites mises à jour
logbsize=256k	Blocs de journalisation plus volumineux	Débit de métadonnées plus élevé
pas de discard	Évite les coûts liés au TRIM synchrone	Au lieu de cela, régulièrement fstrim

Planificateurs d'E/S : none, mq-deadline et autres.

Les contrôleurs NVMe gèrent eux-mêmes efficacement les requêtes, c'est pourquoi j'utilise souvent none au mieux et garde ainsi le Overhead faible. Pour les charges de travail soumises à des contraintes strictes en matière de latence, je teste mq-deadline, car cela permet de stabiliser les temps de réponse, même si le débit maximal diminue légèrement. Alors que bfq Même s’il se distingue par son interactivité, il est rarement le premier choix sur un serveur NVMe. Je ne fais mon choix qu’après avoir effectué des mesures avec fio, qui mesurent séparément les IOPS, le débit et la latence pour les opérations de lecture/écriture et aléatoires/séquentielles. Je développe les détails permettant de comparer les différentes options dans ce petit Guide du planificateur d'E/S, avant de mettre ce paramètre en production.

Adapter les charges de travail de manière ciblée

Les bases de données comportant de nombreuses opérations de validation tirent parti d'un nombre modéré d'AG, de blocs 4K alignés, noatime et relevé logbsize, afin que les transactions de métadonnées s'exécutent rapidement. Je configure les tâches d'analyse et les pipelines de streaming avec une plus grande allocsize et davantage de readahead pour un débit séquentiel élevé. Pour les données brutes d'IA/ML et un grand nombre de workers parallèles, je préfère opter pour davantage d'AG, noatime, les allocations groupées et none en tant que planificateur. Les sauvegardes ou les opérations d'archivage bénéficient en outre d'une exécution périodique fstrim, afin de soulager le système de « garbage collection » du SSD. Je valide chaque ajustement à l'aide de séries de mesures reproductibles avant de Défauts remplacer de manière permanente.

Interpréter rapidement les symptômes courants

Si XFS affiche le message „ No space left on device “ alors qu'il reste manifestement de l'espace disponible, cela signifie souvent qu'un seul AG est saturé ; c'est pourquoi je procède à une redistribution des données, agcount et vérifie les espaces de métadonnées libres. J'interprète généralement une latence anormalement élevée lors de petites écritures aléatoires comme le signe d'un alignement de blocs inadapté, d'un allocsize ou des mises à jour trop fréquentes des métadonnées. Dans de tels cas, les blocs 4K permettent d'utiliser des tranches d'allocation plus grandes et noatime, afin de regrouper les opérations d'écriture. Si la charge du processeur au niveau du système de fichiers augmente de manière notable, il se peut que le nombre de groupes de travail (AG) ait été trop élevé, en particulier lorsque le système de fichiers est presque plein. Dans ce cas, je réduis le nombre de groupes de travail lors d'un reformatage ou j'agrandis la partition afin de Administration de réduire les coûts.

Aperçu des paramètres : vérification rapide

Pour les configurations récurrentes, j'ai sous la main une petite liste de contrôle que je passe en revue avant chaque formatage, ce qui me permet ainsi Constance qui influent sur les performances. Je commence par vérifier la taille physique des secteurs, la profondeur de la file d’attente et les fonctionnalités du contrôleur des périphériques NVMe. Ensuite, je définis le nombre ou la taille des AG et je règle la taille de bloc sur 4 Ko. Enfin, je définis des options de montage adaptées à la charge et je prévois un fstrim. Pour finir, je teste différentes variantes de planificateurs d'E/S et je recense la combinaison la plus rapide pour chaque cas d'utilisation.

Planification étape par étape d'un nouveau système de fichiers XFS sur NVMe

Pour commencer, je détermine la capacité, la taille physique des secteurs, la taille typique des fichiers et le nombre de threads parallèles, afin que la Planification des groupes de travail démarre de manière optimisée. Ensuite, je formate en ajustant le nombre d'AG, la taille de bloc à 4 Ko et en spécifiant des paramètres d'inode facultatifs si je prévois un grand nombre de petits fichiers. À l'étape suivante, je monte le volume avec noatime, plus adapté allocsize ainsi que des paramètres de journalisation optimisés, puis je vérifie les résultats à l'aide de fio. Vient ensuite le choix du planificateur, pour lequel je none et mq-deadline je compare tout en gardant un œil à la fois sur les IOPS et la latence. Pour finir, je mets en place un système de surveillance et je planifie fstrim, afin d'assurer la performance à long terme constant reste inchangée et qu'il n'y ait pas de surprises.

Intégration dans des environnements d'hébergement

Dans les scénarios d'hébergement impliquant des conteneurs, des piles Web et des bases de données, une configuration XFS soigneusement planifiée se traduit directement par un gain en termes de temps de réponse et Débit . Je tiens compte de la profondeur de la file d'attente et du nombre de workers parallèles afin de combiner de manière judicieuse le nombre de groupes de travail et le planificateur. J'ai trouvé une explication détaillée expliquant pourquoi la longueur de la file d'attente sur NVMe donne le rythme dans l'article consacré à la Profondeur de la file d'attente élaboré. Pour les microservices traitant de grandes quantités de données, j'augmente souvent readahead, regroupez les allocations et effectuez des mesures itératives après chaque modification. Ceux qui exploitent leurs applications sur des serveurs gérés ou root performants bénéficient ainsi d'une faible latence, d'un haut niveau de parallélisme et d'un fonctionnement facilement planifiable sur XFS.

Choisir judicieusement les liens de réflexion, les inodes et les fonctionnalités liées aux métadonnées

Lors de la mise en forme, je détermine si CoW/Reflink est adapté à mon cas d'utilisation. Avec mkfs.xfs -m reflink=1 J'active les options « Copy-on-Write » et « Clones rapides », ce qui permet de gagner de l'espace et du temps lors de la création de nombreuses copies, d'images de machines virtuelles ou d'artefacts de build. Pour les bases de données générant un volume d'écriture important, je désactive Reflink (reflink=0), afin de réduire la surcharge liée aux métadonnées et d'alléger le volume des journaux. De plus, je vérifie finobt (Free-Inode-B-Tree), qui accélère les décisions d'allocation pour de nombreux inodes et qui est généralement déjà activé dans les outils actuels.

Le Taille des inodes je décide de -i taille=. Pour les charges de travail comportant de nombreux attributs étendus (ACL, SELinux, métadonnées d'application), je choisis 512 ou 1 024 octets, afin que les attributs puissent souvent tenir dans l'inode et ne se retrouvent pas dans des blocs séparés. Exemple : mkfs.xfs -f -b size=4096 -i size=512 /dev/nvme0n1. Les inodes plus volumineux occupent un peu d'espace, mais permettent de réduire le nombre d'accès lorsque les métadonnées sont fréquemment lues ou écrites. Des fonctionnalités telles que bigtime elles étendent la plage d'horodatage utilisable des systèmes modernes et constituent un choix judicieux pour les nouvelles installations, sans impact négatif mesurable sur les performances. Sur des structures optionnelles telles que rmapbt Je renonce généralement aux volumes de performance purs, car s'ils améliorent avant tout la facilité de gestion et la vérifiabilité, ils entraînent toutefois une charge de travail supplémentaire.

Journal externe, taille du journal et alignement des bandes

Pour les charges riches en métadonnées, il est recommandé d'utiliser un périphérique de journalisation (journal) distinct sur un deuxième disque NVMe à très faible latence, afin de minimiser la concurrence entre les données utiles et les écritures dans le journal. Je configure cela lors du formatage avec -l logdev=/dev/nvme1n1,size= et réglez la taille du journal de manière à ce que les phases de pics de trafic ne déclenchent pas constamment des « log forces » (souvent entre 1 et 4 GiB, selon le modèle de transaction). En combinaison avec logbufs/logbsize Sur Mount, un journal externe stabilise sensiblement les temps de transaction lorsque de nombreux petits fichiers ou mises à jour de métadonnées sont générés.

Si le NVMe est derrière un RAID ou un Device-Mapper, j'aligne le système de fichiers XFS sur la taille des bandes afin que les opérations d'écriture coïncident parfaitement avec les limites des bandes. Cela s'effectue lors du formatage via -d su=,sw=. Ensuite, je vérifie les valeurs à l'aide de xfs_info /mount. Important : ces paramètres ne peuvent pas être modifiés ultérieurement sans reformatage. Sur un disque NVMe unique sans striping sous-jacent, je laisse XFS se charger de l'ajustement automatique.

S'assurer de l'alignement des partitions et des blocs

Avant de formater, je crée des partitions alignées sur 1 MiB afin que les blocs du système de fichiers coïncident parfaitement avec les limites physiques de 4 Ko. Avec parted -a optimal ou une configuration GPT correspondante, j'évite ainsi les décalages indésirables. Je vérifie la taille effective des secteurs physiques et logiques à l'aide de cat /sys/block/nvme0n1/queue/physical_block_size et logical_block_size. Ce n'est que lorsque cette base est solide que les blocs 4K et les portions d'allocation déploient pleinement leur effet.

Contrôler l'E/S directe, le cache de pages et le writeback

Pour les bases de données et les flux de journaux qui gèrent leur propre cache, je configure spécifiquement O_DIRECT, afin d'éviter une mise en cache double dans le cache de page. XFS s'adapte très bien à cette situation, tant que je n'effectue pas simultanément une mise en mémoire tampon mixte et une écriture directe sur les mêmes fichiers. Pour les charges de travail de streaming, une valeur plus élevée readahead le débit : blockdev --setra 4096 /dev/nvme0n1 (soit 2 Mio) est une valeur de départ pragmatique que je mesure et que j'ajuste plus précisément si nécessaire.

Pour équilibrer le système, j'ajuste avec précaution les seuils de réécriture. Au lieu d'utiliser des pourcentages, je préfère me baser sur des valeurs absolues afin d'éviter une accumulation excessive de données sales dans les configurations à grande mémoire vive. Exemple (à tester avec prudence) :

sysctl -w vm.dirty_background_bytes=268435456
sysctl -w vm.dirty_bytes=2147483648

Je préviens ainsi les longues vagues de flush qui augmentent les latences. Je consigne ces paramètres pour chaque hôte afin qu'ils restent reproductibles et ne soient pas modifiés à mon insu par les paramètres par défaut de la distribution.

Tirer parti de la topologie des files d'attente et du CPU

NVMe utilise l'E/S multi-file d'attente : chaque cœur de processeur dispose généralement de ses propres files d'attente matérielles, ce qui me permet de ne pas laisser au hasard la répartition des IRQ et l'affinité CPU. Un processus en cours d'exécution irqbalance C'est la valeur de référence ; dans certains cas particuliers liés à la latence, je configure les IRQ NVMe via /proc/irq/*/smp_affinity ciblant spécifiquement les cœurs proches de NUMA. cat /sys/block/nvme0n1/queue/scheduler affiche le planificateur actif, nr_requêtes et rq_affinity influencer la manière dont les requêtes sont réparties entre les files d'attente. Pour les workers fortement parallélisés, j'augmente, à titre d'essai, /sys/block/nvme0n1/queue/nr_requests modéré, afin de mieux amortir les pics sans surcharger le pilote.

De plus, je peux régler avec précision la regroupement des interruptions des périphériques NVMe (fonctionnalité du contrôleur). Une augmentation modérée des paramètres de regroupement permet de lisser la charge des IRQ, sans toutefois compromettre les objectifs de latence. Je documente toujours ces interventions avec fio‑les centiles de latence, avant leur mise en production.

Quotas, projets et isolement

Dans les environnements multi-locataires, je mise sur Quotas de projet, afin que les charges et l'encombrement restent bien séparés. Je procède au montage avec prjquota et gère les frontières via xfs_quota y compris /etc/projects et /etc/projid. Cela permet, par exemple, de limiter strictement les répertoires de build, les instances de base de données ou les répertoires de mandants, sans restreindre le parallélisme des groupes de travail.

Pour les arborescences de répertoires à forte charge d'ingestion, qui écrivent de manière séquentielle un grand nombre de fichiers volumineux, le flux de fichiers‑Allocator peut s'avérer utile. Il regroupe davantage les fichiers d'un répertoire et réduit la fragmentation. Je l'active de manière ciblée via une option de montage pour les volumes clairement destinés au streaming, et je mesure son impact sur le débit et la charge CPU.

Croissance, instantanés et cycle de vie

XFS peut se développer en ligne, mais pas diminuer. C'est pourquoi je planifie la capacité et la configuration des groupes de disques de manière à ce que les extensions futures via LVM/VMDK puissent s'effectuer sans problème. Avec xfs_growfs /mount j'étends le système de fichiers vers le haut, la structure des groupes de travail s'agrandit en conséquence. Des paramètres tels que sunit et swidth sont définies ; toute modification des géométries RAID doit donc être accompagnée d'un reformatage et d'une restauration.

Pour des résultats cohérents Instantanés En combinaison avec LVM ou des backends de stockage, je « gèle » brièvement le système de fichiers : xfs_freeze -f /mount, Créer un instantané, xfs_freeze -u /mount. Cela réduit au minimum les relectures des journaux et garantit des restaurations sans problème. En ce qui concerne la santé du système en exécution, je prévois de réaliser régulièrement xfs_scrub (le cas échéant) et je garde xfs_repair disponible en tant qu'outil hors ligne. Données SMART, journal intelligent nvme et iostat -x figurent sur ma liste de surveillance afin de détecter rapidement toute dégradation.

Méthodologie de test et références fiables

Avant de remplacer les valeurs par défaut, je procède à des mesures reproductibles. Je commence par définir clairement fio‑Des profils qui prennent en compte séparément les IOPS, le débit et la latence, et qui incluent des phases de préchauffage :

[global]
ioengine=io_uring
direct=1
runtime=60
time_based=1
group_reporting=1
randrepeat=0

[randread-4k]
filename=/data/testfile
rw=randread
bs=4k
iodepth=64
numjobs=8

[randwrite-4k]
filename=/data/testfile
rw=randwrite
bs=4k
iodepth=64
numjobs=8

[seqread-1m]
filename=/data/testfile
rw=read
bs=1m
iodepth=32
numjobs=4

[seqwrite-1m]
filename=/data/testfile
rw=write
bs=1m
iodepth=32
numjobs=4

En fonction de l'objectif, j'adapte numjobs vers les cœurs du processeur et iodepth à la profondeur de file d'attente souhaitée. Il est important que les conditions limites soient cohérentes (même niveau de remplissage, options de montage identiques, volume correctement ajusté). Je filtre les valeurs aberrantes en comparant les moyennes et les 99e centiles de plusieurs exécutions. Cela me permet de prendre des décisions éclairées entre none et mq-deadline, entre le plus petit et le plus grand allocsize ou pour savoir si un journal externe est vraiment utile.

Réglage fin d'allocsize, de Reflink et autres.

allocsize C'est un outil utile, mais ce n'est pas une panacée. Dans le cas d'écritures mineures purement aléatoires, des blocs d'allocation trop volumineux génèrent un effort d'écriture inutile. Je choisis donc des valeurs prudentes en fonction de la charge de travail et je vérifie la fragmentation ainsi que la latence. Lorsque Reflink est activé, j’évite les mises à jour mineures répétitives dans les mêmes zones de fichier, car le CoW implique un surcroît de travail lié aux métadonnées. Si j’ai besoin de clones rapides, je maintiens une grande taille pour les tampons de journalisation et je veille à disposer de beaucoup d’espace libre et contigu dans plusieurs groupes de travail (AG).

Valeurs par défaut sûres : barrières, rejet et cohérence

Obstacles à l'écriture (Barrières d'écriture) et FUA sont activés par défaut sur les piles modernes – je ne les modifie pas, afin d'éviter tout risque de perte de données. nobarrier Cela n'entre pas en ligne de compte pour moi, même si certains benchmarks affichent une légère hausse à court terme. discard sur le Mount ne s'affiche pas, le système-large fstrim‑Timer effectue le TRIM de manière efficace pendant les périodes d'inactivité. Cette combinaison me garantit une faible latence et une performance durable du SSD.

En bref

XFS évolue horizontalement grâce aux groupes d'allocation et tire ainsi parti du parallélisme inhérent à NVMe de manière efficace. Je ne détermine pas le nombre d'AG, la taille des blocs, les options de montage et le planificateur au feeling, mais en fonction du profil de charge de travail et des données de mesure. Pour les petites écritures aléatoires, un alignement précis et un planificateur allégé sont essentiels ; pour les flux importants, il vaut mieux opter pour des allocsize et la lecture anticipée. Je résous les problèmes courants, tels que les groupes de travail déséquilibrés ou les rejets synchrones, par une redistribution et une mise à jour périodique fstrim. En agissant systématiquement sur ces paramètres, on maintient un faible taux de latence, on augmente le nombre d'IOPS et on garantit une performance durable Performance.