J'ai besoin de vos lumières car 2 disques SSD de mon NAS maison sont subitement devenus lents au bout d'un an et demi sans que j'arrive à comprendre la raison.
Configuration
La machine est un NAS tournant sous Debian bookworm, équipé d'un CPU i5-9400 (2.9 GHz) et de 16 Mo de RAM. Elle dispose de 5 disques :
- Un disque NVMe de 250 Go pour le système en ext4 (Samsung SSD 970 EVO Plus)
- Deux disques durs de 8 To pour les données en btrfs raid1 (Seagate IronWolf)
- Deux disques SSD de 2 To pour les services tournant sur le NAS en btrfs raid1 (Samsung SSD 870 QVO 2TB)
Les disques SSD servent à stocker les données des services tournant sur le NAS dans des containers docker: nextcloud, home-assistant, dokuwiki, pihole, influxdb, grafana, jupyter, roundcube, grist, timelimit photoprism, uptime-kuma… Ils servent aussi pour les images de deux machines virtuelles faisant tourner FreeIPA sour RockyLinux et de serveur de fichier pour un raspberry-pi (LibreElec) qui boot sur le réseau local.
Cette configuration tourne sans sourciller depuis 1 an et demi. Les serveurs SSD avaient été ajoutés car les disques durs avaient du mal à supporter les accès simultanés pour les machines virtuelles et les containers.
Début des ennuis
Il y a une semaine je remarque sur mes graphiques grafana que les cpu ont une proportion importante du temps en iowait. Je m'apperçois qu'aux alentours du 8 juillet, les iowait sont passés subitement de environ 1 % à environ 8 %. Je suis un peu étonné car aucun changement n'est intervenu à ce moment et aucun des services ne semble avoir une charge anormale.
Après des investigations plus poussées (iostat, iotop, strace…) j'arrive à isoler la source des ces iowait : les accès au système de fichier btrfs des disques SSD sans vraiment pointer vers un service en particulier.
Le temps des tests
Tout d'abord, j'ai vérifié qu'aucun service n'était responsable à lui seul de cette nouvelle charge. En les éteignant successivement, on se rend facilement compte que l'augmentation des iowait ne peut pas être relié à un service en roue libre.
Ayant eu des déboires dans le passés à le système btrfs sur des noyaux anciens lorsque le nombre de snapshot devenait trop important, je suis passé du kernel 6.1.0 (debian stable) à 6.7.12 (debian backport). Aucun impact. De toute façon, ce système de fichier à assez peu de snapshots.
Deuxième suspect : l'oublie d'activer le Trim sur ce système de fichier via l'option discard=async. Je me dis que le firmware a du mal à trouver des secteurs libres même si seulement 600 Go sont utilisés sur les 1,8 To. Effectivement la commande fstrim -v met un temps fou à s’exécuter et annonce avoir libéré plus d'un To de données. Impact sur les iowait : aucun.
Toujours suspicieux du système btrfs, je décide de passer en ext4 (sur un raid1 logiciel). Impact sur les iowait : aucun.
Je me rend compte que je n'ai pas vraiment libéré les données (du point de vue du firmware) sur les disques lors du formatage. Je tente alors le Security Erase. Mais celà ne marche pas (bloqué par le BIOS), je tente alors sur un des deux disques la commande suivante : blkdiscard. Après une re-synchronisation de ce disque dans le raid : aucun impact sur les iowait.
Bilan des courses
Je suis un peu à court d'idées quant à la raison de cette perte de performance subite. Je pense que faire un blkdiscard sur le second disque ne changera rien. Je ne vois qu'un défaut sur les disques SSD mais j'avoue l'avoir mauvaise de constater cette perte de performance en moins de 2 ans, surtout que les disques m'annoncent qu'ils ne sont qu'à environ 35 % de leur espérance de vie (Wear_Leveling_Count). Ce qui me surprend par dessus tout est l'apparition de ce problème sur les 2 disques à 48 heures d'intervalle.
Je suis preneur d'idées pour retrouver les performances d'il y a 10 jours.
PS : plus de données techniques
- iowait qui passe de 1 % à 8 % (moyenne)
- loadavg qui passe de 0.3 à 1.3-2.5
- write_time multiplié par 10. D'abord sur 1 disque pendant 12 heures; retour à la normal pendant 20 heures; de nouveaux ce disque; rejoint par le second 28 heures plus tard. L'augmentation est soudaine : en moins d'une minute.
- read_time inaffecté
- écritures constantes avant et après : ~40 op/s / 1 Mo/s
- lectures négligeables.
- Absolument rien dans les logs
- Température des disques raisonnable : 45°C
- SMART tests (short et extended) sans erreur
Des graphes pour illustrer : https://grafana.monte-stello.com/public-dashboards/c840519c184949768b736e48f7908de6
# modeles identiques
Posté par Psychofox (Mastodon) . Évalué à 7.
Je n'ai pas de réponse à la question proprement dite mais ce n'est pas super malin de faire des raid1 avec deux disques du même modèles.
Je sais que les serveurs des grandes marques viennent en général avec des disques identiques parce que ça leur fait moins de SKU à gérer, mais ce n'est pas la meilleure des pratiques, et encore moins sur les SSDs.
# je sais !
Posté par BAud (site web personnel) . Évalué à 10.
wow, forcément c'est devenu lent :p déjà que ça boote relève dur miracle :/
# Mauvaise catégorie ?
Posté par jeanas (site web personnel, Mastodon) . Évalué à 8.
Ce journal n'aurait-il pas davantage sa place comme question dans la section Forum ?
# QLC
Posté par gUI (Mastodon) . Évalué à 9.
Les Samsung QVO sont des QLC, j'aurais tendance à simplement accuser cette techno vraiment limitée. Je ne sais pas si ce ralentissement est attendu au bout de 1 an et demi, mais ils sont entre autre réputés pour leur bien plus faible endurance.
En tous cas je ne jouerais pas à en faire tourner H24.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: QLC
Posté par littlebreizhman . Évalué à 9.
Avec un SSD Samsung de génération précédente (je ne me souviens pas si c'était des QLC, j'ai eu le même problème, mon ssd est devenu subitement extrêmement lent après 2 ans.
Rien a faire, même pas la mise à jour du firmware, formatage divers n'a permis de retrouver des performances normales.
Probablement la raison de la dégradation de ton raid
[^] # Re: QLC
Posté par Micromy (site web personnel) . Évalué à 2.
Obsolescence programmée ou firmware codé avec les pieds ?
[^] # Re: QLC
Posté par Psychofox (Mastodon) . Évalué à 9.
Plutôt réduction des coûts et système optimisé pour donner de bonnes performances à l'achat dans un but purement marketing.
[^] # Re: QLC
Posté par rahan . Évalué à 4.
Mon modèle de SSD a une garantie de 3 ans ou 720 To TBW (Total Bytes Written): Samsung SSD Limited Warranty For All Samsung SSDs
Mes SSD ont 46 To ou 50 To TBW. On est loin des limites mais effectivement, le choix de QLC n'était peut-être pas pertinent pour un NAS…
[^] # Quelle est la meilleure alternative à la mémoire QLC ?
Posté par Eridor . Évalué à 5.
Quelle est la meilleure alternative à la mémoire QLC ? MLC ? SLC ? DLC ? TLC ? La fiche Wikipédia donne une idée mais toutes ces technologies de mémoire se valent-elles entre les différents fabricants ? Est-ce le point le plus important à vérifier pour avoir un bon SSD ?
[^] # Re: Quelle est la meilleure alternative à la mémoire QLC ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
SLC (single level cell) stocke 1 bit par transistor (le transistor est chargé ou déchargé)
DLC (dual level) en stocke 2 (4 niveaux de charge)
TLC (triple level) en stocke 3 (8 niveaux de charge)
QLC (quad level) en stocke 4 (16 niveaux de charge)
MLC veut dire "multi level cell" et veut donc juste dire "ce n'est pas du SLC".
Le coût du disque est proportionnel (en gros) au nombre de transistors. Donc un disque SLC coûtera le même pris qu'un QLC pour stocker 4 fois moins de données. Mais ce sera plus fiable, parce que utiliser autant de niveaux différents dans un transistor, ça demande une électronique qui fonctionne de façon assez précise, ce qui est compliqué sur le long terme (les composants vieillissent).
Les disques SLC seront donc les plus fiables mais aussi les plus chers. Le QLC aura une plus grande capacité mais sera moins fiable.
Il ne serait pas complètement surprenant que le firmware passe sur un algorithme d'écriture plus lent, mais plus fiable, au bout d'un certain nombre d'heures de fonctionnement ou de cycles d'écriture, pour compenser le vieillissement des transistors qui se réécrivent de moins en moins facilement avec le temps. Ce qui permettrait d'avoir des bonnes performances sur un disque neuf, mais une fiabilité correcte sur le long terme. Mais ce n'est pas très honnête.
# Taux d'occupation des disques
Posté par ekyo . Évalué à 4.
Quel est le taux de remplissage des disques ?
Pour les modèles bas de gamme ayant peu de cache, après avoir dépassé un certain seuil de remplissage, les performances chutent brutalement. Je n'ai pas investigué le problème, mais peut être le controleur se sert-il de l'espace disponible pour servir de cache ?
[^] # Re: Taux d'occupation des disques
Posté par rahan . Évalué à 4.
475 Go utilisé sur 1,8 To soit 28 % d'utilisation. On est loin du disque rempli. Mais c'est une bonne remarque, ça faisait parti des mes soupçons premiers (btrfs gère mal les disques pleins, sans Trim activé le contrôleur peut penser que le disque est plein, ma volonté de faire un formatage par le firmware…)
[^] # Re: Taux d'occupation des disques
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Pas de cache (ça n'aurait pas vraiment de sens: un cache est intéressant s'il est plus rapide que ce qu'il remplace), mais par contre avoir de l'espage vide déclaré au disque (via trim ou blkdscard, je ne connait pas exactement les commandes à utiliser sous linux) hermet de pré-effacer ces zones pour ensuite pouvoir les écrire. Sur de la mémoire flash, il faut effacer une zone avant de l'écrire, et l'effacement prend plus de temps que la lecture.
On gagne donc des meilleures performance si le disque peut se préparer d'avance des secteurs effacés et prêts à écrire.
D'autre part, il y a le "wear levelling": le disque déplace en permanence des données peu souvent modifiées d'un endroit à un autre sur le disque, dwune part afin d'avoir un nombre d'écritures équivalent sur tous les blocs, et d'autre part parce que si on laisse des données trop longtemps sans les réécrire, elles finissent par s'effacer petit à petit au bout de quelques années.
[^] # Re: Taux d'occupation des disques
Posté par gUI (Mastodon) . Évalué à 3.
Il me semble bien que certains TLC/QLC on qques dizaines de Go en SLC comme cache.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Taux d'occupation des disques
Posté par Claude SIMON (site web personnel) . Évalué à 1. Dernière modification le 19 juillet 2024 à 06:26.
D'autres utilisent la RAM de l'ordinateur.
Pour nous émanciper des géants du numérique : Zelbinium !
# pas de TRIM?
Posté par wismerhill . Évalué à 5.
Est-ce que le TRIM est bien exécuté régulièrement sur tous les SSD? Sinon, une fois que tous les secteurs auront été utilisés au moins une fois, le performances vont considérablement se dégrader.
Cela se fait typiquement via la commande fstrim, et si le système tourne avec systemd, il devrait y avoir un fstrim.service, qui peut être exécuté régulièrement par un fstrim.timer (c'est ce dernier qui doit être activé).
# Les SSD recommandés par un fabricant de NAS
Posté par Crao . Évalué à 1.
Voici le résultat :
https://www.cachem.fr/guide-ssd-nas/
Sans surprise les SSD d'entrée de gamme sont fortement déconseillés (Crucial BX500 et Samsung QVO).
Il y a également le Kingston DC600M SSD 2.5” Enterprise SATA SSD qui est prévu pour les NAS.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.