Pourquoi un pool SSD peut-il se bloquer lors d'écritures soutenues sur un NAS domestique ?

Un pool de SSD peut se bloquer lors d'écritures NAS domestiques soutenues lorsque les données entrantes dépassent le rythme auquel les pages sales, les transactions du système de fichiers, les membres du pool et les contrôleurs SSD peuvent achever un travail durable. Une fois que le tampon atteint une limite, la contre-pression retarde les nouvelles écritures jusqu'à ce que suffisamment de données en file d'attente soient vidées.

Ce mécanisme au niveau du pool est plus large que le remplissage du cache pseudo-SLC d'un SSD ou la collecte des ordures. Une pause visible peut provenir de l'écriture différée de l'hôte, de la synchronisation des transactions copy-on-write, de la latence de vidage, d'un membre lent, de la maintenance du périphérique, ou de plusieurs couches s'alignant en même temps.

Que signifie un blocage d'écriture au niveau du pool ?

Un blocage ne nécessite pas que le débit reste exactement à zéro. Il peut apparaître comme un pic de latence brutal, un intervalle bref proche de zéro, un graphique de transfert en dents de scie, ou une application attendant une écriture synchrone pendant que le débit en arrière-plan continue ailleurs. La latence en queue révèle souvent cet état avant une moyenne de débit à long terme.

Le pool accepte le travail via plusieurs files d'attente. Les applications soumettent des écritures, le noyau peut salir des pages mises en cache, le système de fichiers forme des transactions et des mises à jour de métadonnées, le groupe distribue les opérations aux membres, et chaque SSD traduit les écritures logiques en activité flash. L'occupation des files d'attente peut augmenter simultanément à plusieurs niveaux, donc une valeur agrégée de profondeur de file identifie rarement la première ressource saturée.

La contre-pression remonte lorsque une couche inférieure ne peut pas accepter le travail au rythme entrant. L'achèvement des périphériques ralentit, les files d'attente du pool s'allongent, les données sales approchent d'une limite, et les écritures des applications finissent par attendre. La couche où l'attente devient visible n'est pas nécessairement celle qui a causé le ralentissement. Une fenêtre de copie de fichier peut se mettre en pause seulement après plusieurs secondes d'accumulation cachée dans la RAM et les tampons du contrôleur.

Pourquoi le transfert peut-il commencer plus vite que la vidange du pool ?

De courtes rafales d'écriture peuvent se terminer dans la RAM, les tampons du système de fichiers, la mémoire du contrôleur ou des zones flash rapides avant que le travail final sur le support ne soit terminé. Le débit affiché pendant cette période reflète l'ingestion dans la chaîne de traitement plutôt que le débit durable de bout en bout. Des tests plus longs révèlent si la chaîne atteint un équilibre ou alterne entre le remplissage et la vidange de ses tampons finis.

Linux documente séparément les seuils d'écriture des données sales : le vidage en arrière-plan commence à une limite, tandis qu'un processus générant des écritures peut être forcé d'effectuer l'écriture à un autre seuil. Cela transforme un chemin initialement asynchrone en attente au premier plan sous une pression soutenue.

Un NAS écrit également plus que la charge utile utilisateur. Les métadonnées en copie sur écriture, les sommes de contrôle, les mises à jour d'allocation, la parité ou les miroirs, les instantanés, les journaux et les catalogues de bases de données peuvent ajouter des opérations. Le ratio dépend du système de fichiers, de la disposition du pool, de la taille des blocs, de l'espace libre et de la charge de travail, donc les octets hôtes ne peuvent pas être traités comme des octets média sans mesure. Les petites réécritures aléatoires peuvent créer un coût de vidange très différent des grandes écritures séquentielles alignées de même taille totale.

Comment la contre-pression se propage-t-elle dans le chemin d'écriture ?

Les étapes ci-dessous peuvent se chevaucher, mais les séparer aide à identifier si le blocage commence au-dessus du pool, pendant la synchronisation des transactions ou à l'intérieur d'un ou plusieurs périphériques.

Le tableau est un modèle de diagnostic, pas une preuve que chaque couche met en tampon toutes les écritures de la même manière. L'E/S directe, la sémantique synchrone, la conception du système de fichiers, la politique de cache du contrôleur et la protection contre la perte d'alimentation peuvent modifier le chemin. Une charge de travail synchrone peut rencontrer immédiatement la latence du périphérique ou du journal au lieu de bénéficier de la longue phase de rafale de copie de fichiers tamponnée.

Corrélez les horodatages entre les couches. Une baisse de transfert qui correspond à une augmentation de la mémoire sale suggère une limite différente d'une baisse qui commence avec la latence de complétion d'un membre alors que les données sales de l'hôte diminuent déjà. Utilisez une horloge commune et un intervalle d'échantillonnage ; sinon, un pic court du périphérique peut sembler sans rapport avec la pause de l'application qu'il a déclenchée.

Pourquoi la synchronisation des transactions peut-elle créer un motif en dents de scie ?

Les systèmes de fichiers en copie sur écriture peuvent accumuler des données de transaction sales et les valider plus tard en tant que lot coordonné. La validation peut déclencher une rafale d'écritures asynchrones, mettre à jour les métadonnées et attendre l'ordre ou la durabilité requise avant que le budget de données sales ne soit à nouveau disponible. Si le travail entrant dépasse la capacité de vidange, chaque nouveau cycle commence avec moins de marge et un délai au premier plan devient plus probable.

OpenZFS documente un limiteur d'écriture des données sales qui retarde les nouvelles écritures à mesure que les données sales approchent de leur limite. Sa documentation du planificateur ZIO décrit également les groupes de transactions entrant périodiquement en synchronisation et produisant des rafales d'écritures asynchrones.

Ces sources prouvent le comportement d'OpenZFS, pas une valeur universelle de réglage de ZFS ni le comportement de Btrfs. Modifier le timing des transactions ou les limites de mémoire sale sans mesurer les implications sur la mémoire, la latence et la récupération peut aggraver les blocages, retarder le travail de durabilité ou déplacer la pression vers une autre couche. Plus de mise en mémoire tampon peut retarder une pause tout en augmentant la quantité de données qui doit ensuite être drainée en une seule intervalle chargée.

Comment un SSD ralentit-il tout le pool ?

Une opération en miroir ou en bande peut dépendre de la complétion de plusieurs membres. Si un SSD développe des queues de latence d'écriture longues, l'opération logique peut attendre même lorsque les autres disques restent rapides. La bande passante agrégée des appareils peut masquer ce retard d'un seul membre. Les modèles de SSD mixtes, les firmwares, les niveaux d'usure et les températures rendent la comparaison au niveau des membres particulièrement importante dans un pool construit maison.

Les SSD grand public peuvent montrer une latence d'écriture soutenue variable car le mappage interne, la collecte des déchets, l'équilibrage d'usure, le repli du cache et les contrôles thermiques entrent en concurrence avec les écritures de l'hôte. Les recherches sur la latence de la collecte des déchets documentent la relation entre la gestion du flash et la performance des SSD, mais ne prédisent pas un disque commercial spécifique. Les mises à jour du firmware et l'espace libre restant peuvent modifier le profil de latence du même disque au fil du temps.

La limite de cet article reste le pool : comment la latence des appareils se propage vers le haut et déclenche une contre-pression. Les questions précédentes sur un seul disque concernant l'épuisement du SLC ou la collecte des déchets doivent être évaluées séparément afin que le même mécanisme ne soit pas utilisé pour expliquer chaque blocage du pool. Un test sain sur un disque individuel ne garantit pas non plus une latence identique lorsque plusieurs membres reçoivent des écritures coordonnées simultanément.

Comment mesurer les blocages d'écriture soutenus ?

Utilisez un transfert suffisamment long pour dépasser la mise en mémoire tampon transitoire et rapporter le débit sur de courtes intervalles ainsi que les percentiles de latence. Enregistrez la mémoire sale, l'écriture différée, le timing des transactions du système de fichiers, la profondeur de la file d'attente du pool, la latence par membre, la température des appareils, l'espace libre et les tâches en arrière-plan. Conservez la taille des blocs de la charge de travail, le comportement de synchronisation, la compressibilité et le schéma du nombre de fichiers car chacun peut modifier l'amplification d'écriture et la surcharge des transactions.

Les statistiques I/O des blocs Linux exposent les requêtes en cours, le temps passé sur les lectures et écritures, et le temps I/O pondéré qui peut refléter un retard accumulé. Les compteurs par appareil sont essentiels car une moyenne du pool peut masquer le membre lent.

Répétez avec les tâches en arrière-plan en pause, puis réintroduisez les snapshots, les scrubs, la réplication, les conteneurs ou l’indexation média un par un. Maintenez l’état d’espace libre du pool stable, car la marge de nettoyage peut modifier le comportement soutenu. Si le réseau semble rapide mais que le pool se bloque toujours, la liste de contrôle des goulots d’étranglement NAS 10GbE peut compléter le diagnostic du chemin sans prouver la cause au niveau du stockage.

FAQ

Un blocage de pool SSD est-il la même chose que l’épuisement du cache SLC ?

Non. L’épuisement du SLC est une cause au niveau de l’appareil d’une vitesse d’écriture soutenue plus faible. Un blocage du pool peut aussi provenir de l’écriture différée de l’hôte, du throttling du système de fichiers, de la synchronisation des transactions, de la latence de vidage ou d’un membre lent.

Un réseau plus rapide peut-il provoquer plus de blocages visibles ?

Oui. Un réseau plus rapide peut alimenter les écritures dans le chemin de stockage plus rapidement, épuisant le tampon plus tôt et exposant le débit soutenu du pool. Il révèle la limite plutôt que de créer la limite de stockage sous-jacente.

Ce modèle de contre-pression s’applique-t-il uniquement à ZFS ?

Non. L’écriture différée tamponnée et les files d’attente des couches inférieures existent au-delà de ZFS, mais la sémantique et les contrôles des transactions diffèrent. La limitation des données sales et les détails du groupe de transactions cités sont spécifiquement un comportement OpenZFS.

Le refroidissement peut-il supprimer les pauses d’écriture soutenues ?

Cela n’aide que lorsque la limitation thermique contribue à la latence de l’appareil. Cela ne peut pas corriger les limites de données sales, la pression de synchronisation des transactions, des performances NAND soutenues insuffisantes ou un membre du pool défaillant.

Quel changement doit être testé en premier ?

Identifiez d'abord la couche où la latence augmente : écriture différée de l'hôte, synchronisation du système de fichiers, membre du pool ou température de l'appareil. Puis modifiez une variable limitée ; mettre à niveau les disques ou ajuster l'écriture différée avant de localiser la limite peut masquer le signal sans le résoudre.

Conclusion finale

Un pool SSD se bloque lorsque des écritures soutenues sur un NAS domestique remplissent le chemin plus rapidement que le travail durable ne s'écoule, forçant une contre-pression sur les requêtes en premier plan. Corrélez les données sales, les rafales de transactions, la latence par membre et la télémétrie des appareils ; des preuves au niveau du pool sont nécessaires avant de blâmer un cache SSD ou un paramètre de système de fichiers. La chronologie identifie la première couche saturée. Cela reste mesurable.