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.

    • [^] # Re: Pas de miracle avec un périphérique à 50 euros les 500G

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

      Je ne peux plus modifier mon commentaire mais j'ajouterai également que ce modèle le BX500 et l'entrée de gamme de chez Crucial évidemment, et est "DRAM-LESS". A bannir.

      Une feuille à mettre dans vos favoris lors de votre prochain achat :

      https://docs.google.com/spreadsheets/d/1B27_j9NDPU3cNlj2HKcrfpJKHkOf-Oi1DbuuQva2gT4/edit#gid=0

    • [^] # Re: Pas de miracle avec un périphérique à 50 euros les 500G

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

      Je rebondis sur le titre «Pas de miracle avec un périphérique à 50 euros les 500G». En fait, à 50€ les 500Go, on trouve aujourd'hui de bons produits commes les Samsung EVO (80€/To sur amazon…). Le prix est similaire en NVMe.

      Pour de l'usage domestique, je pense que c'est le bon rapport qualité/prix en ce moment. Bien sûr il y a des ratés, comme ce BX500 un peu pourri, mais sinon ça fait le taf.

      Il faut se méfier avec la pseudo équivalence prix <=> qualité, les bons élèves sont souvent assez discrets.

    • [^] # Re: Pas de miracle avec un périphérique à 50 euros les 500G

      Posté par  . Évalué à 3 (+2/-0). Dernière modification le 06 mai 2024 à 18:59.

      Que le SSD soit rempli ou pas, il ne passe pas son temps à faire du "TRIM", il faut déjà que ça soit configuré au niveau de l'OS pour faire du TRIM en temps réel, et le TRIM concerne essentiellement l'effacement de fichier, pour indiquer au SSD quelles sont les emplacements réellement libres (le SSD n'est accédé que par bloc et ne peut "comprendre" le fonctionnement du filesystem).

      Quand un SSD est presque plein, c'est comme sur un disque magnétique, le filesystem est plus lent mais en principe ça se sent un peu moins. Le fait d'avoir de la DRAM sur le SSD ne joue pas en accès séquentiel (ici ave hdparm), ça joue un peu en écriture et en accès aléatoire local. Rien ne vaut le cache RAM de l'OS de toutes façons, au plus près du processeur.

      Mais là ce n'est même pas la question, le test est fait via "hdparm" qui se contente de lire séquentiellement le disque, le débit ne peut pas baisser normalement. Et ici, vu les débits hdparm tombés à 2 Mo/s voire moins, le SSD a vraiment un problème, ce n'est pas normal.

    • [^] # Re: Pas de miracle avec un périphérique à 50 euros les 500G

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

      Trim n'a rien à voir avec une défragmentation… C'est juste qu'une mémoire flash s'écrit avec une granularité au bit mais s'efface par secteur (physiques, effacé = tout à 1, l'écriture ne sait que passer des bits à 0 sur un secteur pré-effacé et un seul bit à baisser => une opération de read/modify/write nécessaire sur un secteur déjà effacé), contrairement à un HDD classique.

      L'effacement étant une opération longue, le FW du SSD doit pouvoir maintenir un pool de secteurs physiques pré-effacés prêts à écrire. Seulement, sur un stockage pas neuf ou tout a déjà été écrit, côté stockage aucun moyen de savoir ce qui est utilisé/alloué par le FS.

      D'ou la commande trim ajoutée afin que le FS côté OS puisse informer le FW du SSD de ce qu'il n'utilise plus côté blocs logiques (LBA) traduits en secteurs physiques par la flash transmission layer, permettant de maintenir un pool se secteurs physiques prêts à écrire au bénéfice des perfs.

  • # 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é à 3 (+2/-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é à 3 (+2/-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é à 6 (+5/-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 (+2/-1).

          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.

  • # Ce n'est pas nouveau

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

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

    Ça n'est pas nouveau… pour les périphériques, la victoire de l'USB sur le duo Firewire/SCSI était annonciateur du pire… et maintenant les ordinateurs tellement complexes qu'on a plus aucune idée de la façon dont ils fonctionnent vraiment, avec des pilotes qui font des centaines de Mo (sous m$ bien sûr).

    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…

    Jamais connu ça en SCSI, sous window$ NT en tous cas, car il est vrai que les window$ "grand public" de la lignée M$-Do$ ne savaient pas exploiter à fond le SCSI…

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.