Journal Attention aux nouveaux SSD, chute des performances ! (Crucial BX500 2To)

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
49
2
mai
2024

Bonjour à tou(te)s,

dans la série merdification de l'informatique : la merdification du matériel.

Après avoir connu les cartes microSD menteuses, l'effondrement des débits des clés USB soi-disant USB2 aussi bien en écriture qu'en lecture, voici maintenant que je me retrouve confronté au même problème avec mon nouveau SSD, un Crucial BX500 2To.

Alors certes son prix est intéressant, certes j'aurai dû me renseigner avant (il y avait une alerte sur le test sur Tom's Hardware), mais je pensais naïvement qu'un SSD restait quand même supérieur à un disque mécanique, au moins un 5400tr.

En fait, dès que le SSD a été un peu rempli (> 50%), les performance tant en écriture mais même en lecture se sont effondrées, avec des lags lors du simple parcours de grands dossiers possédant eux-même plusieurs sous-dossiers !

Le plus insupportable, qui ne devait concerner que les disques mécaniques : les accès concurrents en lecture ! Si j'ai le malheur d'écouter un MP3 et de faire autre chose en même temps, la musique fait des pauses régulièrement ! C'est un retour 20 ou 30 ans en arrière…

Apparemment c'est dû à la combinaison de la mémoire flash QLC et de l'absence de cache DRAM.

C'est trop tard pour moi, j'écris ce journal juste pour que d'autres ne se fassent pas avoir !

Bonne journée,
A. Louali

# sudo hdparm -t /dev/sda1

/dev/sda1:
 Timing buffered disk reads: 1032 MB in  3.02 seconds = 342.08 MB/sec

# sudo hdparm -tT /dev/sda1

/dev/sda1:
 Timing cached reads:   46706 MB in  1.99 seconds = 23470.32 MB/sec
 Timing buffered disk reads:  32 MB in 11.30 seconds =   2.83 MB/sec

# sudo hdparm -t /dev/sda1

/dev/sda1:
 Timing buffered disk reads:   2 MB in 12.09 seconds = 169.46 kB/sec

# sync
# sudo hdparm -t /dev/sda1

/dev/sda1:
Timing buffered disk reads:  16 MB in  6.54 seconds =   2.45 MB/sec

  • # Pas de miracle avec un périphérique à 50 euros les 500G

    Posté par  . Évalué à 10 (+9/-0).

    Voila .. Surtout que full le périphérique doit passer son temps à faire du "trim" (de la réallocation de blocks pour retrouver de la place … ) du bon vieux "défragementation Windows" à l'ancienne :D

    Fonction de la qualité du contrôleur de la quantité de DRAM attaché au périphérique c'est plus ou moins rapide … l'idée étant toujours de tirer sur la corde pour être le "mieux placé" dans les prix, rien d'étonnant.

    Cela dit, le phénomène se ressent également (dans une moindre mesure évidemment) sur les périphériques à plusieurs milliers d'euros sur le matériel pro (HPE/Dell) sur des gros workload, quand le SSD est plein, ça commence à se sentir. Surtout si le firmware est moisi ou ne sais pas gérer ça correctement et qu'il faut passer par la couche system pour lancer les batch de trim.

  • # inflation des prix

    Posté par  . Évalué à 4 (+3/-1).

    j'ai acheté un Crucial P5 Plus, 1To l'année passée fin juin, à 65€, dans une boutique toulousaine. Il est actuellement à 110€ et 99€ sur une boutique en ligne en 4 lettres.

    Ca pique !

  • # BX = entré de gamme Crucial

    Posté par  . Évalué à 3 (+2/-0).

    j’ai déjà utilisé la série BX de crucial et je préfère rester sur la série MX quand je fais des mises à jour du matériel, la différence c’est la vitesse de lecture/écriture supérieur et le chiffrage sur le MX que tu n’as pas sur le BX, tu as un support simple pour faire les mise à jour firmware du SSD.

    Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.

  • # Pas possible

    Posté par  (site web personnel) . Évalué à 3 (+2/-0). Dernière modification le 04 mai 2024 à 16:12.

    Ces chiffres me semblent vraiment anormaux, même pour un BX500.
    Le manque de DRAM et/ou le QLC ne peuvent pas suffir à expliquer une aussi basse performance en lecture.
    Je dirais plutot soit le SSD à un problème, soit c'est un fake chinois, soit un problème software/bios…

    • [^] # Re: Pas possible

      Posté par  (site web personnel) . Évalué à 3 (+2/-0).

      Peut être essaye un

      fstrim /point/de/montage

      • [^] # Re: Pas possible

        Posté par  . Évalué à 2 (+1/-0). Dernière modification le 06 mai 2024 à 19:02.

        Pour moi c'est clair que le SSD a un problème, ce n'est pas du tout normal d'avoir du hdparm aussi lent, un simple accès séquentiel à bas niveau (et ça n'a pas de rapport avec du TRIM ou une absence de cache DRAM sur le SSD, cf mon commentaire plus haut).

        PS : j'ai un Crucial MX500 de 2 To qui ne m'a pas semblé cher à l'achat (par rapport à d'autres) et j'en suis très content.

        • [^] # Re: Pas possible

          Posté par  (site web personnel) . Évalué à 2 (+1/-0).

          Ici l'auteur semble utiliser le SSD en disque root, monté en r/w.
          Il est tout a fait probable que le SSD soit sollicité en écriture pendant les tests hdparm.

          Sur un SSD sans DRAM, avec plus aucun bloc libre (dont le SSD à connaissance via trim), pour écrire le moindre octet sur le SSD, il doit d'abord aller lire un bloc entier, l'effacer, modifier le bloc avec l'octet en question, et ré-écrire tout le bloc.

          Cela amène à un comportement exactement comme décrit (gros lags, etc.), qui arrivent à un moment ou le SSD à été suffisamment utilisé pour que plus aucun bloc ne soit libre du fait de l'absence de trim fonctionnel.

    • [^] # Re: Pas possible

      Posté par  (site web personnel) . Évalué à 2 (+1/-0). Dernière modification le 04 mai 2024 à 19:09.

      Perso, je ne suis même pas étonné. J'ai eu le même modèle (en 1To), et j'ai fini par en changer car j'avais très régulièrement des freeze du PC durant une dizaine de seconde. Un enfer au quotidien. Bref, pour appeler un chat un chat, c'est juste un modèle de merde.

      • [^] # Re: Pas possible

        Posté par  (site web personnel) . Évalué à 5 (+4/-0).

        C'est un mauvais SSD on est bien d'accord. Mais je vérifirai quand même que le trim est bien fonctionnel :

        Vérifier que le ssd est soit :

        • monté avec "discard" comme option de montage :
        mount | grep discard
        • soit que fstrim.timer est bien activé :
        systemctl status fstrim.timer

        Tenter un 

        fstrim -av

        Pour voir

        • [^] # Re: Pas possible

          Posté par  . Évalué à 2 (+1/-0).

          Ce n'est pas une bonne idée d'activer le TRIM en temps réel je crois.

          Il vaut mieux laisser le system faire une passe TRIM à intervalle régulier. Sur mon Ubuntu c'est configuré par défaut en cron (une fois par nuit ou une fois par semaine, je ne sais plus), ça lance "fstrim". Sinon quand je fais de gros effacements (j'efface des films enregistrés par exemple), je lance un "fstrim" moi-même sur le montage.

          • [^] # Re: Pas possible

            Posté par  . Évalué à 1 (+0/-0).

            C'est l'option discard qui dans fstab force le nvme/ssd à trim en permanence.

            La bonne pratique semble être d'activer fstrim qui est lancé par fstrim.timer qui le lance une fois par semaine grace à systemd. Source trust me bro …. (plus sérieusement voir les kb Rhel ou les pages Arch à ce sujet)

  • # Crucial P2

    Posté par  (site web personnel) . Évalué à 3 (+2/-0).

    J'avais acheté à une époque un Crucial P2 qui devait normalement utiliser de la TLC. Après quelques mois d'utilisation, je trouvais qu'il se bloquait souvent lors de grosses écritures. Il s'avère que Crucial a changé les puces utilisées sans changer le nom du produit. La version que j'ai achetée est en QLC. Voir https://www.tomshardware.com/features/crucial-p2-ssd-qlc-flash-swap-downgrade.

    Depuis, j'évite cette marque qui avait pourtant bonne réputation pour moi.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.