Disque NVMe, performance ?

Salut à tous,

J’avais commencé à rédiger ce message en réponse au sujet récent de @Stéph sur une mise à niveau de sa configuration mais j’ai réalisé que ça ferait sortir du sujet ; je préfère donc poster dans un nouveau sujet en taggant les personnes du sujet, pour voir s’ils ont quelque chose à dire : @sgble et @CyberS@m.

Je me demandais récemment : est-ce que le cache que l’OS effectue en RAM ne réduit pas l’impact d’un disque NMVe par rapport à du SSD en SATA ? Ou alors l’impact vaut vraiment le coup là où il se fait sentir : lors de l’accès à des fichiers non ouverts depuis le démarrage (lors du démarrage, lancement de logiciels ou première ouverture d’un projet, etc.) ?

J’ai eu des retours très positifs sur la mise à niveau de SSD SATA vers SSD PCI NMVe, mais principalement par des joueurs. De mon côté, je n’ai pas l’impression d’attendre mon disque souvent pour du développement (à part pour de l’analyse sur des fichiers type log, et encore, la décompression est probablement le facteur limitant).

J’ai l’impression que l’avantage principal est pour ceux traitant du contenu ne pouvant pas rentrer en mémoire, ou alors assez volumineux pour que le temps de mise en RAM est important. Je pense ici aux joueurs et à ceux qui touchent à du multimédia (vidéo, photo, audio).

Je ne connais pas bien la politique de mise en cache des différents OS ; une idée de ces politiques pourrait aider ici.

Alors, des retours pour du développement ?

Salut,

est-ce que le cache que l’OS effectue en RAM ne réduit pas l’impact d’un disque NMVe par rapport à du SSD en SATA ?

Franchement, oui.

Comme critère qui peut représenter une bonne raison de réduire la latence d’accès aux données d’un SSD, je propose la ferme de déchiffrement de flux GSM A5/1 : https://brmlab.cz/project/gsm/deka/start

Je n’ai pas d’autre idée.

Hello,

Déjà, un premier point pragmatique : aujourd’hui les SSD NVMe et SATA sont approximativement aux mêmes prix, sauf peut-être si tu cherches les grosse capacités (comme 4 To). Comme le NVMe n’a pratiquement que des avantages sur le SATA (latence, débit maximum, nombre d’opérations réalisables en parallèle) à l’exception du nombre de ports généralement disponibles¹, il n’y a plus vraiment de raison logique de se limiter au SATA si le NVMe est disponible.

L’avantage en débit brut va rarement servir, sauf à manipuler peu de gros fichiers (copies, certaines opérations de virtualisation (démarrage/arrêt/pause de la VM), montage vidéo, chargement de certains jeux…)

L’avantage en latence et en nombre d’opérations par seconde va servir quand tu manipules beaucoup de petits fichiers, c’est-à-dire un peu tout le temps en fait. C’est surtout visible au démarrage, en développement (surtout sur des projets un peu volumineux) et pour certaines opérations de virtualisation (toute lecture/écriture sur la VM une fois démarrée, qui se fait généralement par blocs de 64 ko).

Sinon, la notion de cache disque ne va intervenir que lorsque les données peuvent être mises en cache, c’est-à-dire lorsque tu vas les relire et que tu as assez de RAM pour qu’elles soient encore dedans. C’est très dépendant de l’usage réel de ton ordinateur et surtout de la quantité de RAM « libre » (donc disponible pour servir de cache). En particulier, pour le développement, dès que le projet grossit tu veux un disque rapide, parce que tu vas souvent avoir besoin d’écrire beaucoup de petits fichiers (en particulier si tu utilises un langage qui se compile, en incluant le JS « moderne »). Et le cache disque de l’OS ne peut rien faire pour les écritures².

La mise en cache et en buffer de Linux (et sûrement des autres OS) aide franchement pas mal à désengager un peu le disque quand on a assez de RAM. Un SSD en SATA fait donc parfaitement l’affaire dans beaucoup de cas.

À vrai dire, je pensais à des cas assez précis hier, en rapport avec le développement (car l’OP parlait de compilation).

Quand le cache est froid et qu’on a multitude de fichier à parcourir (exemple du grep), c’est sympa d’avoir du NVMe, mais on peut s’en passer, surtout quand le cache est déjà chaud (au pire, tu fais un petit script pour chauffer le cache avec fadvise au boot si tu en as besoin toute la journée par la suite).

Mais je pense notamment à une application où l’on cherche à outrepasser les optimisations de l’OS pour forcer l’écriture physique en temps réel : les bases de données. Leur garanties les forcent en général à ne pas se contenter d’un simple write mais à indiquer au système qu’il faut écrire physiquement sur le disque maintenant, grâce à un appel fsync par exemple. Chaque petit UPDATE ou INSERT sur une DB peut donc se traduire par une écriture physique immédiate, là où d’autres applications plus tolérantes (presque toutes) auraient laisser l’OS gérer ça tout seul. Dans ce cas, l’OS bufferise comme il l’entend en RAM avant d’écrire une bonne fois pour toutes sur le disque, limitant par là même le nombre d’accès physiques et la latence qui y est associée, et améliorant ainsi les performances globales.

Exiger une écriture physique pour chaque écriture « logique » a donc un coût non-négligeable si le workload attendu est lourd en écriture (une DB d’analytics, par exemple), mais c’est le prix à payer pour amoindrir au maximum les pertes de données si un problème apparaît (déconnexion du disque, coupure de courant, …).

Dans le cas où l’on s’attend à faire plein de petites écritures physiques en direct (sans bufferiser), l’intérêt d’avoir une faible latence au niveau matériel prend donc tout son sens pour améliorer les performances de ce workload-ci. Le prix à payer est alors en numéraire : les disques de ce genre sont les plus chers (surtout en gamme pro), et il faudra les remplacer au bout d’un certain nombre d’octets écrits (cela réduit leur durée de vie). Dans un setup d’entreprise, ce n’est pas forcément un problème : remplacer des disques morts ou presque c’est la routine… De plus, il est souvent possible de monitorer le nombre d’octets écrits via S.M.A.R.T. pour prévoir le remplacement.

Je précise que ce problème de durée de vie est le même sur des SSD SATA.

Bien entendu, ce comportement est plus ou moins configurable selon les DB, et ce n’est pas que pour les BDD relationnelles (Redis aussi peut être configuré pour offrir de telles garanties par exemple).

Juste pour préciser que :

1. Les disques NVMe n’utilisent pas SMART mais directement les commandes du protocole NVMe (certains outils SMART peuvent les lire, comme smartmontools sous Linux, mais pas tous les outils et il manquera des infos – sous Linux on installera plutôt nvme-cli).
2. Le problème de la durée de vie est un faux problème pour l’immense majorité des usages personnels (ou même professionnels-sur-le-poste-de-travail) : on écrit tout simplement pas assez pour atteindre les limites d’usage des disques. Le problème se pose vraiment pour les usages serveur.

Par exemple, mon SSD NVMe Force Series MP510 960 Go M.2 me déclare 5.9 To écrits pour une durée de vie de 1700 To écrits (pourtant il contient mon /home, j’y fais du dev, et il me sert à stocker les jeux « en cours » donc avec de grandes séries de données régulièrement réécrites).

Mon antique SSD SATA 2.6 (3.0 Gbts) Intel X25-M de 80 Go qui doit avoir 10 ans maintenant plafonne à 17 To de données écrites.

Aujourd’hui un SSD de 1 To pas cher en QLC (qui sont moins endurants en écriture) est quand même donné pour 200 To écrits.

Juste pour préciser que :

1. Les disques NVMe n’utilisent pas SMART mais directement les commandes du protocole NVMe (certains outils SMART peuvent les lire, comme smartmontools sous Linux, mais pas tous les outils et il manquera des infos – sous Linux on installera plutôt nvme-cli).

J’utilise en effet smartmontools, d’où ma méprise ! Je pensais qu’il s’agissait là aussi du même SMART

J’aurais appris quelque chose !

2. Le problème de la durée de vie est un faux problème pour l’immense majorité des usages personnels (ou même professionnels-sur-le-poste-de-travail) : on écrit tout simplement pas assez pour atteindre les limites d’usage des disques. Le problème se pose vraiment pour les usages serveur.

Nous sommes d’accord. D’ailleurs, même sur des workloads serveur avec un usage plus classique (disons la DB de ZdS), on a le temps avant d’épuiser les écritures d’un SSD. De mon expérience, j’ai vu des disques (d’entreprise) rendre l’âme avant même d’atteindre leur limite d’écriture…

Mais, dans mon taf actuel, on des serveurs qui sauvegardent en continu des séquences de vidéos et ça fait pas mal grimper le taux d’écriture (surtout pour le contenu HD voire 4K). Notre infra est physique donc on surveille donc nos disques de près !

Salut

N’ayant pas encore eu la possibilité de tester réellement un SSD M.2 NVMe, je ne pourrais pas te répondre précisément sur la différence avec un modèle SATA (NVMe ou de 2,5", ça revient au même en termes de performances) mais si, pour le moment, elle semble être faible (enfin, tout dépend de l’utilisation), les nouvelles consoles en utilisant elles-aussi, il est fortement probable que cette différence soit bien plus visible à "long terme".

Par contre, comme l’a dit SpaceFox, les prix des 2 types de SSD (SATA et NVMe) étant plus ou moins les mêmes, aujourd’hui, mieux vaudrait prendre un SSD M.2 NVMe (surtout que la plupart des cartes mères sont équipées, be base, d’au moins 1 radiateur spécifique qui permettra d’éviter au maximum les surchauffes qui pourraient réduire pas mal leurs performances)… ils sont même parfois moins chers : les CRUCIAL P1 et KINGSTON A2000 (en Anglais) sont très bien mais, si ton budget le permet et/ou que tu as envie de te faire plaisir, le meilleur choix serait les KINGSTON KC2000/KC2500 (en Anglais) en PCIe 3.0 et le CORSAIR Force MP600 en PCIe 4.0.

Intéressant tout ça, merci à vous. L’évolution des prix est vraiment folle quand même, j’avais acheté mon SSD 120Go 120€ d’occasion. Pour ce prix, on trouve désormais des disques M.2 NVMe 1To neufs.

J’ai pu observer les statistiques de ce vieux SSD, il est à 15–16To.

Niveau serveur, ça arrive ? J’ai l’impression que c’est principalement pour des disques systèmes (pour l’OS), je n’ai pas vu de lames faites pour accepter un grand nombre de SSD au format M.2.

Il y a bien des CM serveur avec du M2 en direct ou des cartes PCIe qui accueillent plusieurs disques en M2.

Mais en général, un châssis serveur a un backplane a l’avant qui permet de retirer et mettre des disques (à chaud ou à froid, en général via SATA et/ou SAS) pour optimiser les opérations de maintenance, car on ne peut pas ouvrir un châssis quand il est racké, or la prise M2 ou l’adaptateur PCIe est sur la CM directement.

(Il existe peut-être des solutions qui rendent les accès PCIe en extérieur, mais je ne les connais pas, si ce n’est des adaptateur USB)

C’est peut-être l’une des raisons qui rend son usage moins commode pour autre chose que l’OS. Toutefois, aucun problème avec des SSD en SATA ou en SAS qui peuvent être branchés via le backplane (quitte à les visser dans un plateau-adaptateur).

Cela dit, tous les serveurs n’ont pas de backplane permettant cela, et selon le cas, on peut accepter d’ouvrir des châssis pour faire des opérations de maintenance dessus. Les disque SSD en NVMe sur M2/PCIe ont donc leur place dans le monde pro, surtout pour des utilisations intensives en petites opérations I/O (je reprends mon exemple des serveurs de BDD).

(je passe de manière irrégulière sur le site, d’où le déterrage)

Concernant les disques serveurs, ce n’est pas le format M.2 qui sera utilisé mais le format U.3. Avec un disque SSD dans un boitier (qui peut accueillir à peu près 2 ou 3 SSD M.2, ce qui fait qu’il y a des SSD U.3 d’une dizaine de To sur le marché).

Pour les serveurs il y a aussi potentiellement l’utilisation d’un switch PCIe pour utiliser plus de SSD qu’il n’y a de lignes PCIe sur le processeur, en considérant qu’on n’utilise que rarement 100% de la bande passante pour le SSD, on peut répartir la bande passante d’un PCIe x4 sur 2 SDD x4 par exemple.
(Cela vient aussi du fait que les processeurs Intel sont un peu à la ramasse en terme de lignes PCIe, pour le coup les AMD Epyc proposent un nombre très important de lignes PCIe).

My 2 cents.

Le U.3 me semble encore très récent, mais je vois que son prédécesseur, le U.2 remplit déjà parfaitement ses fonctions : on a en gros du NVMe possible, mais avec une prise/formfactor semblable aux disques SATA, permettant ainsi l’échange à chaud des disques. (Ce qui en M.2 n’est pas possible, je pense)

Pour les serveurs il y a aussi potentiellement l’utilisation d’un switch PCIe pour utiliser plus de SSD qu’il n’y a de lignes PCIe sur le processeur, en considérant qu’on n’utilise que rarement 100% de la bande passante pour le SSD, on peut répartir la bande passante d’un PCIe x4 sur 2 SDD x4 par exemple.

Je suppose que les Cloud providers utilisent cette technique pour les VPS, ce qui peut expliquer les performances disque parfois désastreuses en « heure de pointe », malgré le marketing qui affiche clairement SSD NVMe

En tout cas, je saurai que je dois privilégier les Epyc la prochaine fois…

Ou tout simplement c’est bien des SSD NVMe, mais en SAN… Donc avec les latences et goulets d’étranglement réseau en plus. Il faut aussi vérifier que l’on te garantit un SSD local.

J’ai cru observer que les SAN ça allait plutôt être les Block Storage qui, effectivement, saturent en débit sur la vitesse de la liaison réseau (souvent 100 ou 200 Mbps). Mais les petits disques fournis en même temps que la VM (sur lesquels l’OS et ses données résident) ont l’air d’être locaux d’après un rapide test avec dd (de mémoire j’avais des résultats satisfaisants proche du baremetal chez OVH, Linode et DigitalOcean, ce qui me fait dire que les disques étaient bien locaux).

Oui dans un datacenter tu peux avoir la partie CPU présente dans un serveur rack qui n’a que ces CPU et relié en réseau à un serveur de données (permettant une gestion plus efficace des données). Mais dans ce cas il y a une latence minimale ainsi qu’un potentiel goulot d’étranglement avec le débit Ethernet max du lien (40G ? 100G ?) mais aussi d’une limite sur le switch pour partager équitablement.

Il n’y a pas forcément à privilégier un AMD Epyc quand tu choisis un serveur. Dans mon boulot on fait des media server qui font qu’on utilise beaucoup de carte graphique et d’acquisition. Or on a réellement besoin d’avoir des liens PCIe x16 dédiés et seul les AMD Epyc en proposent suffisamment. La gamme Intel propose moins de ports dédiés et a recours à des switch sur les cartes mères.

Dans le cadre des serveurs, on peut se permettre de mettent 2 CPU donc c’est pas gênant en fait.