Auteur Sujet: Performance des SSD - Disques en usage réel  (Lu 1713 fois)

0 Membres et 1 Invité sur ce sujet

alain_p

  • Client Free fibre
  • *
  • Messages: 5 879
  • Les Ulis (91)
Performance des SSD - Disques en usage réel
« Réponse #12 le: 15 août 2018 à 15:53:43 »
Mais dans un volume Ceph, on peut mélanger les SSDs et les disques SATA/SAS, ce qui n'est pas le cas dans un volume Raid, et je peux te dire que quand on a mis des disques SATA dans un volume Ceph avec des disques SSDs, cela fait sacrèment baisser les performances de l'ensemble.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 565
  • La Madeleine (59)
Performance des SSD - Disques en usage réel
« Réponse #13 le: 15 août 2018 à 15:58:08 »
Mais dans un volume Ceph, on peut mélanger les SSDs et les disques SATA/SAS, ce qui n'est pas le cas dans un volume Raid, et je peux te dire que quand on a mis des disques SATA dans un volume Ceph avec des disques SSDs, cela fait sacrèment baisser les performances de l'ensemble.

Tu peux tout à fait mélanger sata, sas, nvme, ssd, disque dur, n'importes quoi, au sein d'une même "grappe" raid

Naturellement, cela tire la performance de l'ensemble vers la performance de l’élèment le plus lent

Hugues

  • AS57199 MilkyWan
  • Expert
  • *
  • Messages: 6 568
  • Paris (15ème)
    • MilkyWan
Performance des SSD - Disques en usage réel
« Réponse #14 le: 15 août 2018 à 17:13:50 »
Mais dans un volume Ceph, on peut mélanger les SSDs et les disques SATA/SAS, ce qui n'est pas le cas dans un volume Raid, et je peux te dire que quand on a mis des disques SATA dans un volume Ceph avec des disques SSDs, cela fait sacrèment baisser les performances de l'ensemble.
Alors que l'inverse, bien configuré, ça met un joli coup de boost a ton cluster :)

alain_p

  • Client Free fibre
  • *
  • Messages: 5 879
  • Les Ulis (91)
Performance des SSD - Disques en usage réel
« Réponse #15 le: 15 août 2018 à 17:28:58 »
Vous êtes sûrs de vous là pour une carte Dell Perc H730p en particulier ? Que l'on puisse avoir deux volumes Raid, l'un avec des SSDs, et l'autre avec des disques NLSAS, oui, mais mélanger les deux au sein d'un même "disque virtuel", ce n'est à ma connaissance pas possible.

Après lecture du manuel utilisateur de la carte H730p :
"La combinaison de disques SAS et SATA au sein d'un disque virtuel n'est pas prise en charge. De même, la combinaison de
disques durs et de SSD au sein d'un disque virtuel n'est pas prise en charge."

https://topics-cdn.dell.com/pdf/poweredge-rc-h330_users-guide_fr-fr.pdf

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 565
  • La Madeleine (59)
Performance des SSD - Disques en usage réel
« Réponse #16 le: 15 août 2018 à 17:45:06 »
Vous êtes sûrs de vous là pour une carte Dell Perc H730p en particulier ? Que l'on puisse avoir deux volumes Raid, l'un avec des SSDs, et l'autre avec des disques NLSAS, oui, mais mélanger les deux au sein d'un même "disque virtuel", ce n'est à ma connaissance pas possible.
Je te parle de raid
Sur cette carte en particulier, aucune idée, je ne connais pas

alain_p

  • Client Free fibre
  • *
  • Messages: 5 879
  • Les Ulis (91)
Performance des SSD - Disques en usage réel
« Réponse #17 le: 15 août 2018 à 20:43:48 »
Là, je me demande si vous ne me parlez pas de raid logiciel (madm) ?

Fuli10

  • Client Free vdsl
  • *
  • Messages: 524
  • Conflans Sainte Honorine (78)
Performance des SSD - Disques en usage réel
« Réponse #18 le: 16 août 2018 à 14:23:18 »
Salut
Juste pour dire que je peux en parti expliquer le pourquoi des benchmark aux résultats étrange. Faut juste que je trouve un peu de temps et un clavier (mieux que le smartphone).
Mais en résumé un bench de SSD tout seul ne donnera sûrement pas le même résultat tout le temps suivant l'utilisation du SSD.
Quoi qu'il en soit vivien, est-ce que le raid géré par le controlleur supporte le passage du trim aux SSD? Et aussi pour aider les écritures (surtout s'il n'y a pas de trim), est-ce que tu as dimensionné le raid pour utiliser 85/90% des 2 SSD?

Zeda

  • Client Orange Fibre
  • *
  • Messages: 108
  • Toulouse (31)
Performance des SSD - Disques en usage réel
« Réponse #19 le: 19 août 2018 à 16:00:29 »
Je suis intéressé pour voir les performances du SSD avec l'outil de test intégré dans Ubuntu.

Un boot sur une clef USB avec Ubuntu 18.04 est suffisant.

=> https://lafibre.info/tutoriels-linux/performance-des-ssd-disques/msg567103/#msg567103

A ta demande vivien, j'ai fait le test sur mon SSD Samsung 970 EVO 250Go M.2 PCIe NVMe.


Fuli10

  • Client Free vdsl
  • *
  • Messages: 524
  • Conflans Sainte Honorine (78)
Performance des SSD - Disques en usage réel
« Réponse #20 le: 20 août 2018 à 00:20:02 »
Bon,
Je vais commencer par un petit speach sur le fonctionnement d'une flash.
Pour accéder à une mémoire flash, une adresse est définie par page (p = puissance de 2, par exemple 8KB), secteur (x pages) et bank (y secteurs).
Pourquoi cette subdivision ?
Parce que quand on fait un accès à la flash, la mémoire convertie l'adresse donnée en une page qu'elle charge ensuite dans un buffer (mémoire) interne. Ce qui permet à la flash une fois la page préchargée d'envoyer les données très rapidement (burstée). La page est donc le plus petit élèment accédé sur une flash. Ensuite x pages (tjrs une puissance de 2) forment un secteur. Un secteur est le plus petit élèment effaçable sur une flash. Dans une flash on n'efface jamais une page mais un secteur tout entier. Il faut noter que l'effacement d'un secteur de flash prend un temps très long (par rapport à la lecture). Sur les premières flash (NOR) cela pouvait prendre de l'ordre de quelques centaines de ms.... Maintenant ça c'est amélioré mais bon cela reste très long. Enfin la bank est la dernière séparation. Une bank est le nombre de secteurs auquel il ne faut plus accéder lors d'un effacement. Et oui, l'effacement d'un secteur étant très long, c'est fait de manière asynchrone (ordre d'effacement, puis lecture à intervalle régulier du status). Problème, il faut laisser la flash "travailler" et donc ne pas accéder aux données en cours d'effacement. Mais en fait c'est même plus compliqué que cela, c'est toute une bank (y secteurs) qui est inaccessible lors d'un effacement.
Pour résumer:
- page: plus petit élèment accédé
- secteur: plus petit élèment effacé
- bank: plus petit élèment inaccessible lors d'un effacement
Côté fonctionnement, une flash contient initialement que des bits à 1, et une écriture consiste à mettre à zéro des bits sur une page. On peut réécrire une page, seuls les nouveaux bits à zéros seront écrits. Il n'est donc pas possible d'écrire un bit à 1. Et donc un effacement consiste à remettre TOUS les bits d'un secteur à 1. Et enfin il faut savoir qu'une page supporte un nombre limite d'écriture de zéros avant de commencer à flancher (= ne pas écrire le zéro). Sur les premiers modèles c'était de l'ordre de plusieurs milliers, maintenant cela se compte en centaines... Mais bon, cela reste des statistiques.
Vous commencez à voir les problèmes avec les filesystem conçus pour fonctionner avec un disque dur (et donc possible d'écrire des zéros et des 1 dans un secteur) ?
Un processeur flash fait donc y*x*p bytes.
Du moins commercialement, car une page c'est un peu plus qu'une puissance de 2...
En fait, il est d'usage de rajouter quelques octets APRES la page. Je ne me rappelle plus combien mais c'est de l'ordre de 16 octets par KO. Pourquoi ces données en plus ? En fait il y a plusieurs raisons à cela:
- cela contient un code correcteur d'erreur (3 octets/512 octets) qui permet de détecter et potentiellement corriger une erreur d'un bit (un seul)/512 octets
- cela contient surtout des paramètres sur l'état de la page et qui est propre à l'algorithme implèmenté dans le contrôleur et qui va s'interfacer avec le PC
Quoi qu'il en soit, dans un SSD affiché à 960GB, il y a des chances pour qu'il y ait au moins 1TB voir même beaucoup plus, ceci sans compter les données extras par page.

Bon, toute cette introduction est là pour dire qu'au final ce qui donne de bonne performances à un SSD c'est surtout l’intelligence (= l'algorithme) de son contrôleur.
En effet, celui ci devra gérer: plusieurs chip flash en parallèle, plusieurs bank inaccessibles lors des effacements, le wear-leveling (= répartition du nombre d'écriture sur la totalité de la flash), et tout ça en prenant bien garde de ne pas perdre de données si le courant est coupé.
D'ailleurs, comme le wear-leveling est très (de plus en plus) important, on va détailler un peu ce que cela doit faire.
Pour le wear-leveling, cela est important car comme une page à un nombre (de plus en plus) limité d'écriture avant erreur, cet algorithme doit répartir les écritures sur le plus de pages différentes de flash possible (donc sur la totalité de la flash). Cela implique obligatoirement que le contrôleur est capable de faire une translation d'adresse du type secteur logique (LBA) -> adresse en flash (complètement différente). Et si jamais une écriture dans un secteur logique a lieu, il faut que le contrôleur choisisse une nouvelle adresse en flash vierge (effacée), écrive les nouvelles données dessus, sauvegarde dans sa structure la nouvelle translation LBA->adresse, et enfin marque la précédente adresse en flash comme "invalide - à effacer". C'est aussi pour ça qu'il y a toujours plus de flash qu'affiché (genre 1TB pour 960GB affiché), cela permet à l'algorithme de wear-leveling de toujours trouver une page vierge.
Avec le wear-leveling vient aussi le garbage collector. Son but c'est d'effacer la flash en background en se basant sur les pages marquées "à effacer". Par exemple quand un secteur logique LBA a été écrit 2 fois. Là c'est facile, l'ancienne adresse en flash de la première écriture doit être effacé. A noter, le TRIM aide énormèment. Dans un filesystem classique prévue pour un disque dur lent, effacer un fichier consiste juste à réécrire quelques secteurs contenant la position du fichier sur le disque et voilà. Ce qui fait qu'avec un SSD on se retrouve avec des données effacés sur le filesystem mais pas en flash et là le garbage collector rame pour trouver des secteurs à effacer. Alors qu'avec le TRIM, on envoi en plus toute la position du fichier effacé sur le disque au controleur du SSD qui peut directement marquer les pages de la totalité du fichier comme "à effacer". Mais comme sur une flash on n'efface pas une page mais un secteur, comment on fait ? Et là c'est la magie du garbage collector qui parfois se retrouve à déplacer quelques pages pour effacer tout un secteur.
Et enfin, si jamais le contrôleur tombe sur une page qui nécessite une correction d'erreur, la page doit être marqué comme "à ne plus utiliser" et les données déplacées sur une nouvelle page.

En fait les problèmes que les contrôleurs doivent gérer en plus avec les filesystem:
- la translation LBA->adresse en flash
- la réécriture d'un secteur
- je n'en ai pas parlé, mais un secteur logique ne fait pas forcement la taille d'une page (512B ou 4KB vs des pages de 8KB parfois)
- le TRIM qui permet de marquer très tôt un fichier à effacer
- le pool de pages vierges

Voilà donc ce qui fait que 2 benchmark ne donnent que rarement le même résultat:
- la translation LBA->adresse en flash peut prendre plus de temps suivant qu'il s'agit d'un secteur jamais accédé avant ou pas
- la translation LBA->adresse en flash peut prendre plus de temps suivant qu'il y ait une grosse fragmentation
- si le garbage collector travail plus ou moins
- suivant le remplissage du SSD
- suivant les performances au globale du contrôleur
- s'il y a des effacements à gérer en parallèle
- ou pas...
- si on écrit que des 1
....
Bref le benchmark rapide d'un SSD cela ne sert quasi à rien pour avoir une idée de ce que cela donnera en condition réelle.

Mes conseils sur les SSD:
- bien vérifier que le TRIM arrive bien aux SSD malgré le RAID
- aider le garbage collector en allouant des partitions un peu plus petites que la taille du disque (genre 10/15% en moins) même s'il y a déjà de la mémoire en plus
- faire plus confiance aux sites qui vérifient la stabilité des performances suivant le remplissage
- les meilleurs performances seront souvent atteint pour une quantité limité de données

Fuli10

  • Client Free vdsl
  • *
  • Messages: 524
  • Conflans Sainte Honorine (78)
Performance des SSD - Disques en usage réel
« Réponse #21 le: 20 août 2018 à 00:31:27 »
Note:
j'ai déjà bossé sur des flash mais cela commence à dater un peu (les dernières supportaient 10000 écritures). Autant sur les SSD cela reste des contrôleurs parfois sur base ARM (de ce que j'ai vu), autant je n'ai aucune idée de comment sont intégrées les flash NVMe vu les besoins en performance de l'interface. S'agit-t-il d'ASIC dédiés avec toujours le même algorithme, ou de contrôleurs ultra rapide (surtout pour faire la translation d'adresse), ou plus bêtement tout l'aspect translation d'adresse et gestion du wear-leveling est fait sur le le processeur principale du PC suivant une norme intégré dans les BIOS modernes....
Quoi qu'il en soit à l'époque j'ai halluciné des gains en performances possible pour linux (3.x à l'époque...) à condition d'accepter du dédié machine. Par exemple la lecture d'une page se fait en 2 fois: la page est lue puis les données extra (la fin de la page). Sachant que cela implique 2 fois la latence de lecture d'une page, on double les performances FS très simplement en lisant d'une passe la page et les extras ! Et encore il y avait d'autres gains faciles à intégrer (alignement de page, lecture initiale, etc)... Bref peut-être aujourd'hui c'est (j'espère) mieux géré mais à l'époque c'était encore le far-west...

vivien

  • Administrateur
  • *
  • Messages: 29 700
    • Twitter LaFibre.info
Performance des SSD - Disques en usage réel
« Réponse #22 le: 20 août 2018 à 10:47:06 »
@Zeda impressionnant le gain de débit lecture du SSD Samsung 970 EVO 250Go M.2 PCIe NVMe
Il multiplie les performances SATA du test par 6 !

@Fuli10 Merci pour ces explications. Dans mon cas (serveur miroir) je n'ai presque aucun besoin en écriture et mes problèmes sont en lecture, sachant que c'est de nombreux petits fichiers qu'il faut lire et pas des gros blocs contigus.

Le système de fichier est Ext4, il y a beaucoup de place disponible (utilisation à 60%) et le kernel Linux est récent (4.13)

Les SSD et la carte RAID sont ceux d'origine de Dell, j'ai juste reconfiguré le RAID 1 d'origine en RAID 0, car Dell ne sait pas proposer un RAID 0 pré-installé.
=> Le RAID 0 est composé de deux SSD Intel 960Go MLC en SATA connecté à la sur la carte RAID Dell PERC H330. C'est du matériel qui a un an (commandé à la rentrée 2017 et installé fin 2017)

Fuli10

  • Client Free vdsl
  • *
  • Messages: 524
  • Conflans Sainte Honorine (78)
Performance des SSD - Disques en usage réel
« Réponse #23 le: 20 août 2018 à 11:23:36 »
Pour tester le trim:
https://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/2/
Pour les performances en lecture, cela vient peut être (supposition maraboutesque) du contrôleur qui "cache" la translation secteur logique->adresse flash. Et dans le cas de lecture de beaucoup de fichiers, si c'est reparti sur tout le disque logique le cache est dépassé...
Note: si le trim ne fonctionne pas, même si le disque est rempli qu'à 60%, le garbage collector n'aura pas effacé 40% du SSD car il ne saura pas si une page contient un fichier effacé ou pas. Du coup le pool de pages libre est réduit.

 

Mobile View