Qu’est-ce qui ralentit un pool de SSD lorsque l’espace libre passe sous les 15 % ?
Un pool SSD ralentit souvent lorsqu’il approche de sa pleine capacité, car le contrôleur et le système de fichiers disposent de moins d’espace de travail propre pour les écritures, la relocalisation, les métadonnées et les instantanés.
Le seuil de 15 % n’est pas une limite universelle, mais il constitue un avertissement utile pour de nombreuses charges de travail de serveur domestique. Le pool peut disposer d’octets logiques libres tandis que les instantanés, l’allocation dynamique, les métadonnées du système de fichiers, les fichiers supprimés mais encore ouverts ou l’absence de prise en charge de discard réduisent l’espace que les contrôleurs SSD et les logiciels de stockage peuvent réellement réutiliser. Diagnostiquez la marge d’écriture effective et la latence d’écriture plutôt que de vous fier à un seul pourcentage affiché dans un tableau de bord.
Confirmez quel indicateur d’espace libre a atteint 15 %
Comparez la capacité brute du SSD, la capacité du pool, l’espace libre du système de fichiers, l’allocation provisionnée dynamiquement, l’utilisation des instantanés, les quotas, les blocs réservés et le volume applicatif qui semble lent. Ces valeurs répondent à des questions différentes.
GNU Coreutils explique que l’espace disponible du système de fichiers est calculé à partir des informations comptables du système de fichiers monté, qui peuvent ne pas inclure tous les éléments du pool, les instantanés, les volumes provisionnés dynamiquement ou les réserves au niveau du contrôleur qui affectent les écritures.
Si un seul jeu de données ou volume provisionné dynamiquement est presque plein, corrigez ce niveau au lieu de considérer que tous les SSD sont lents. Si l’ensemble du pool dispose de peu de capacité non allouée, poursuivez avec les vérifications de l’espace de travail du contrôleur, du discard et des instantanés.
Comprenez pourquoi les écritures NAND nécessitent un espace de travail propre
Mesurez la latence des écritures soutenues et aléatoires de petite taille avant et après le franchissement du seuil par le pool. La vitesse de lecture peut rester acceptable tandis que les écritures deviennent intermittentes ou irrégulières.
Crucial décrit le surprovisionnement SSD comme une capacité réservée au nettoyage, au nivellement de l’usure et aux blocs de remplacement, ce qui explique pourquoi une marge d’écriture plus faible peut accroître la relocalisation en arrière-plan lors de nouvelles écritures.
Ne supposez pas que chaque ralentissement signifie que la mémoire flash est usée. Un SSD en bon état peut devenir temporairement lent lorsqu’il doit effacer, déplacer et réécrire davantage de données valides pour chaque nouvelle écriture.
Vérifiez que le discard ou le TRIM atteint les SSD
Vérifiez si les blocs supprimés du système de fichiers sont rejetés en continu, périodiquement ou jamais. Incluez chaque couche située entre le système de fichiers et le SSD : chiffrement, RAID, provisionnement dynamique, HBA, disque virtuel et boîtier.
L’opération retrim d’Optimize-Volume de Microsoft montre que les blocs supprimés doivent être communiqués à travers la pile de stockage afin que le périphérique puisse les préparer pour leur réutilisation.
Une commande réussie au niveau du système de fichiers ne prouve pas que le SSD a reçu le discard. Comparez les compteurs du périphérique ou le comportement d’écritures contrôlées avant et après une opération TRIM prise en charge, et n’activez pas le discard à travers une couche qui ne le préserve pas de manière sûre.
Vérifiez les instantanés, les corbeilles et les fichiers supprimés mais encore ouverts
Mesurez l’espace occupé par les instantanés, les clones, les dossiers de rétention, les corbeilles, les journaux de bases de données et les fichiers ouverts dont les entrées de répertoire ont été supprimées. Ces éléments peuvent maintenir les blocs alloués alors que les utilisateurs pensent que les données ont disparu.
La documentation ZFS d’Oracle explique que les instantanés conservent les blocs référencés. La suppression d’un fichier actif volumineux ne libère donc pas forcément son espace lorsque des instantanés plus anciens dépendent encore de ces blocs.
Supprimez uniquement les points de rétention qui dépassent la politique définie et confirmez quels blocs ils référencent. Un instantané volumineux n’est pas automatiquement obsolète, et sa suppression en urgence peut éliminer le seul moyen de récupérer une modification récente.
Faites la distinction entre le surprovisionnement du contrôleur et l’espace libre du système de fichiers
Vérifiez si chaque SSD dispose d’un espace de réserve non partitionné, d’une zone de rechange définie par le fabricant ou d’un surprovisionnement géré par l’hôte. L’espace libre du système de fichiers et la réserve du contrôleur ont des fonctions liées, mais différentes.
Kingston explique que le surprovisionnement côté hôte laisse une capacité non allouée, afin que le contrôleur SSD dispose d’un espace de travail supplémentaire au-delà des blocs libres visibles par le système de fichiers.
Ne réduisez pas un pool actif sans sauvegardes vérifiées et sans procédure de réduction prise en charge. Le surprovisionnement est plus sûr lorsqu’il est planifié avant le déploiement ou mis en place pendant une migration contrôlée.
Exécutez un TRIM pris en charge et mesurez la récupération
Après avoir supprimé les données et les instantanés inutiles, exécutez l’opération de discard prise en charge par la plateforme pendant une période de faible charge. Notez le nombre d’octets rejetés et vérifiez si la latence d’écriture évolue une fois que le SSD a terminé son nettoyage en arrière-plan.
Le manuel de fstrim explique que le discard s’applique aux blocs inutilisés du système de fichiers et que le retraitement répété des mêmes régions peut ne présenter aucun avantage supplémentaire.
Un TRIM qui indique zéro octet n’est pas automatiquement un échec : le système de fichiers a peut-être déjà été nettoyé, ou une couche intermédiaire peut bloquer le discard. Appuyez-vous sur les informations propres à la pile de stockage avant de modifier les options de montage.
Rétablissez une marge d’espace et vérifiez le véritable goulot d’étranglement
Déplacez les données temporaires, supprimez uniquement les instantanés autorisés par la politique, compactez les bases de données lorsque cette opération est prise en charge et rétablissez une marge délibérée d’espace libre. Répétez ensuite la même charge d’écriture en mesurant la latence, la profondeur de file d’attente, l’attente CPU et la température des SSD.
L’article de ZimaSpace sur les signes avant-coureurs d’un cache SSD présente la limite voisine entre une pression liée à l’espace, réversible, et les indices d’une défaillance du périphérique lui-même.
Le diagnostic est terminé lorsque la latence d’écriture s’améliore après la vérification de la marge disponible ou la récupération liée au discard, que les instantanés et les métadonnées restent conformes à la politique et que la même charge demeure stable au-dessus de la réserve choisie. Si les performances restent médiocres malgré un espace suffisant, recherchez une limitation thermique, l’usure, des erreurs du contrôleur, le comportement du RAID ou les E/S de l’application.
Produits recommandés
Assistance et conseils
Plus à lire
Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...
Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...
Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...
