Stockage : NVMe vs SSD SATA — Le test de charge qui change tout

Le test de charge qui change tout

L’erreur la plus fréquente dans les débats « NVMe vs SATA » est de benchmarker la mauvaise charge. Les gens lancent un test de lecture séquentielle, obtiennent un gros chiffre et se déclarent vainqueurs. Puis en production ça cale encore parce que la charge réelle fait des petits écrits aléatoires synchrones, ou des accès mixtes avec une latence de queue abominable. Votre activité ne tourne pas sur le MB/s de pointe. Elle tourne sur des temps d’achèvement prévisibles.

Le test de charge qui change tout est simple :

• Mesurer les percentiles de latence, pas seulement les moyennes.
• Utiliser des tailles de bloc réalistes (souvent 4K–16K pour les bases, 128K+ pour streaming/sauvegarde).
• Inclure les semantiques de sync si votre application utilise fsync/FDATASYNC.
• Varier la profondeur de queue et la concurrence jusqu’à voir où la latence explose.
• Exécuter assez longtemps pour atteindre l’état stable (les SSD ont du cache et des comportements de wear-leveling ; les tests courts mentent).

Pourquoi cela change les décisions : les SSD SATA semblent souvent « corrects » à faible profondeur de queue et faible concurrence. Beaucoup de systèmes de production ne sont pas légers. Dès que vous ajoutez concurrence, compactage en arrière-plan, checkpoints, écritures de log et trafic réel des utilisateurs, le SATA atteint un mur plus tôt. NVMe n’augmente pas seulement le plafond ; il modifie la forme de la courbe.

Voici le modèle mental : SATA est un couloir étroit avec une file indienne. NVMe est un entrepôt avec plusieurs quais de chargement et des chariots élévateurs qui n’utilisent pas tous une seule porte. Le test de charge, c’est vous qui apportez assez de camions pour voir où se trouve vraiment le goulot.

NVMe vs SATA en pratique (pas le marketing)

Protocole et tuyauterie : pourquoi NVMe existe

Les SSD SATA utilisent un protocole conçu pour les disques rotatifs. Ça fonctionne, mais c’est une couche de traduction avec des hypothèses héritées : moins de queues, profondeur de queue limitée, plus d’overhead CPU par I/O, et un modèle de contrôleur hôte optimisé pour « une file de requêtes » plutôt que pour « des milliers d’opérations concurrentes ».

NVMe a été conçu pour le flash dès le départ. Il supporte de nombreuses queues de soumission/complétion, de grandes profondeurs de queue, un overhead réduit et un parallélisme propre. Sur un serveur moderne avec beaucoup de cœurs CPU, ça compte. Le stockage n’est pas juste un périphérique ; c’est un pipeline à travers le noyau, les pilotes, le fabric PCIe, le firmware du contrôleur et les couches de traduction NAND. NVMe est le premier protocole grand public où le pipeline ne joue plus à faire comme si nous étions en 2005.

Différences de performance que vous ressentirez réellement

Trois choses décident si vous sentirez l’avantage NVMe :

1. Latence sous charge : SATA peut avoir une latence respectable à faible profondeur de queue. Sous charge, il s’arrime plus vite et la latence de queue devient rapidement désagréable.
2. IOPS pour les petits I/O aléatoires : NVMe domine généralement ici, en supposant que le disque et le système sont corrects.
3. Charges mixtes : NVMe gère en général les lectures/écritures concurrentes avec moins d’interférence mutuelle.

Et une chose décide si vous ne verrez rien : si vous êtes limité par le réseau, le CPU, ou si l’application est sérialisée, NVMe n’est qu’un moyen coûteux de se sentir vertueux. Une mise à niveau de stockage ne corrige pas des plans de requête mauvais.

Fiabilité et comportement opérationnel (la partie qui fait mal à 3h du matin)

Tant les NVMe que les SSD SATA peuvent être fiables. Les deux peuvent échouer de façons qui ressemblent d’abord à « l’appli est lente » avant de ressembler à « le disque est mort ». Opérationnellement, NVMe vous donne une télémétrie plus riche via SMART/log pages (selon les outils), et souvent un meilleur comportement de latence sous pression. Mais il introduit aussi d’autres modes de défaillance : affaiblissement du lien PCIe, bugs firmware, throttling thermique, et changements de pilote noyau qui mordent lors des mises à jour.

La plupart des équipes sous-estiment la surface opérationnelle du « plus rapide ». Les périphériques plus rapides amplifient les hypothèses fragiles. Si vos options de système de fichiers sont incorrectes, NVMe vous aidera à atteindre une mauvaise conclusion plus rapidement.

Faits et histoire qui comptent vraiment

• SATA descend de ATA/IDE, une famille conçue pour les disques durs et lecteurs optiques, pas pour le flash à faible latence.
• AHCI (l’interface hôte SATA courante) a été pensée à l’ère des HDD, où les attentes de queueing et de parallélisme étaient modestes.
• NVMe 1.0 est arrivé au début des années 2010, spécifiquement pour éviter les inefficacités des stacks hérités sur les SSD.
• NVMe supporte de nombreuses queues matérielles, permettant un meilleur scalage sur plusieurs cœurs CPU ; c’est un gros avantage sur les serveurs multi-socket.
• Le comportement de « cache SLC » des SSD rend les benchmarks courts trompeurs : beaucoup de disques grand public et même certains disques entreprise accélèrent en rafale puis ralentissent fortement.
• Le test 4K random write est historiquement celui qui « les fait pleurer » car il stresse les couches de traduction flash et l’amplification d’écriture.
• TRIM/DISCARD compte : sans lui, les performances soutenues peuvent se dégrader car le SSD dispose de moins d’espace libre pour gérer.
• La journalisation des systèmes de fichiers et le WAL des bases ont été optimisés initialement pour les contraintes des HDD ; les SSD déplacent les compromis.

Métriques qui tranchent le débat

Percentiles de latence : les chiffres adultes

La latence moyenne, c’est pour les slides. Le p95/p99/p99.9, c’est ce que ressentent vos utilisateurs, ce que vos retries amplifient, et ce pourquoi vos SRE se font réveiller. L’avantage principal de NVMe en production n’est souvent pas le débit maximal ; c’est éviter que la latence de queue ne devienne incontrôlable sous concurrence.

Profondeur de queue et utilisation : où le goulot apparaît

Quand un périphérique sature, la latence augmente parce que les requêtes patientent en file. Vous verrez un await plus élevé dans iostat, des files plus profondes dans iostat -x, et des latences plus longues dans fio. SATA tend à saturer plus tôt pour les I/O aléatoires petits. NVMe peut aussi saturer—tout peut—mais le « genou » de la courbe est généralement plus loin.

IOPS vs bande passante : arrêtez de les confondre

IOPS, c’est « combien d’opérations par seconde ». La bande passante, c’est « combien de données par seconde ». Une charge de lectures aléatoires 4K a faim d’IOPS. Une charge de lectures séquentielles 1MB a faim de bande passante. Si vous mesurez la mauvaise, vous achetez le mauvais disque.

Amplification d’écriture et état stable

Les SSD effectuent du garbage collection interne. Ils déplacent des données pour libérer des blocs, ce qui signifie que le périphérique peut écrire plus que ce que vous lui avez demandé. Sous écritures soutenues—surtout aléatoires—les performances peuvent chuter après que les caches sont remplis. Tout benchmark qui n’exécute pas assez longtemps pour atteindre le comportement d’état stable est essentiellement une démo.

Idée paraphrasée — Werner Vogels : « Concevez pour la panne ; supposez que les composants vont casser, et construisez des systèmes qui continuent de fonctionner quand même. »

Ce n’est pas que de la philosophie. C’est de l’ingénierie du stockage : vous concevez pour la queue lente, le voisin instable, le RAID dégradé, le disque qui throttle et le noyau qui décide de changer les valeurs par défaut.

Un montage de test sensé (pour ne pas benchmarker votre page cache)

Règles d’engagement

• Benchmarker un périphérique bloc brut ou un fichier de test dédié avec I/O directe, pas votre page cache.
• Utiliser une taille supérieure à la RAM. Si votre serveur a 64 Go RAM, ne testez pas avec 4 Go.
• Verrouiller l’environnement : gouverneur CPU, tâches cron en arrière-plan, voisins bruyants (hôte VM), et options de montage du système de fichiers.
• Décider ce que vous optimisez : débit, latence, latence tail, ou cohérence sous charge.

Blague 1 : Les benchmarks de stockage sont comme les régimes : tout le monde a un plan jusqu’à ce que le cache atteigne sa limite.

Choisir des charges représentatives

Quelques profils couvrent la plupart des systèmes réels :

• Base OLTP : 4K–16K random reads/writes, mixte, concurrence modérée à élevée, comportement fsync/WAL.
• Ingestion de logs : écritures séquentielles, fsync périodique, lectures occasionnelles pour indexation.
• Hôtes VM/conteneurs : I/O aléatoires mixtes sur de nombreux invités, souvent le pire cas pour la latence tail.
• Analytics/ETL : grandes lectures séquentielles, quelques grosses écritures, en rafales.
• Stockage objet/Ceph : nombreuses petites opérations, surcharge de réplication, interaction réseau + disque.

Tâches pratiques : commandes, sorties et la décision que vous prenez

Voici les tâches que j’exécute quand quelqu’un dit « le disque est lent » ou « on devrait acheter du NVMe ». Chacune inclut une commande réaliste, une sortie exemple, ce que ça signifie et la décision qu’elle entraîne.

Task 1: Identify what’s actually attached (NVMe vs SATA, model, firmware)

cr0x@server:~$ lsblk -d -o NAME,MODEL,TRAN,SIZE,ROTA
NAME MODEL                      TRAN   SIZE ROTA
sda  Samsung_SSD_860_EVO_1TB     sata 931.5G    0
nvme0n1 Samsung_SSD_980_PRO_1TB  nvme 931.5G    0

Ce que cela signifie : Vous avez à la fois des périphériques SATA et NVMe. ROTA=0 confirme un SSD (non rotatif). TRAN indique le transport.

Décision : Benchmarkez le bon appareil et arrêtez de débattre abstraitement. Aussi : consignez modèle/firmware ; un NVMe grand public et un NVMe entreprise se comportent très différemment sous charge soutenue.

Task 2: Check PCIe link width/speed (NVMe can be silently crippled)

cr0x@server:~$ sudo nvme id-ctrl /dev/nvme0n1 | egrep -i 'mn|fr|rab|ieee'
mn : Samsung SSD 980 PRO 1TB
fr : 5B2QGXA7
rab : 6
ieee : 002538

cr0x@server:~$ sudo lspci -vv -s $(readlink -f /sys/class/nvme/nvme0/device | awk -F/ '{print $(NF-1)}') | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x4
LnkSta: Speed 8GT/s (downgraded), Width x2 (downgraded)

Ce que cela signifie : Le NVMe fonctionne à une vitesse/largeur PCIe réduite. Cela arrive avec de mauvais slots, réglages du BIOS, risers ou problèmes thermiques.

Décision : Corrigez la plateforme avant d’accuser le disque. Si votre « NVMe » est effectivement sur la moitié d’une voie, vous avez payé une voiture de sport et installé des pneus de vélo.

Task 3: See if the kernel thinks your disk is constantly busy

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (server) 	02/04/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.11    0.00    4.20    8.35    0.00   75.34

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz  aqu-sz  %util
sda              5.10    180.4     0.00   0.00   12.30    35.35   95.20   4200.0    10.00   9.50   45.60    44.12    4.38  99.20
nvme0n1         30.00   1200.0     0.00   0.00    0.85    40.00  110.00  5200.0     0.00   0.00    1.40    47.27    0.22  22.50

Ce que cela signifie : sda est saturé à ~99 % d’utilisation avec un write await élevé ; nvme0n1 cruise. Le iowait CPU est non négligeable. C’est un goulot stockage sur le périphérique SATA.

Décision : Déplacez le chemin chaud hors du SATA, ou réduisez la pression d’écriture (regroupement, moins de fsync, meilleur caching). Si les données de l’application résident sur sda, NVMe ailleurs ne vous aidera pas.

Task 4: Confirm the scheduler and request settings (especially for SATA)

cr0x@server:~$ cat /sys/block/sda/queue/scheduler
[mq-deadline] none

cr0x@server:~$ cat /sys/block/nvme0n1/queue/scheduler
[none] mq-deadline kyber bfq

Ce que cela signifie : NVMe tourne souvent mieux avec none. Les SSD SATA se comportent souvent bien avec mq-deadline pour contrôler la latence sous contention.

Décision : Si la latence monte en flèche sur SATA sous charge, essayez mq-deadline. Si vous tentez « d’optimiser » NVMe en forçant BFQ, vous pourriez inventer des problèmes.

Task 5: Check TRIM/discard support and whether it’s being used

cr0x@server:~$ lsblk -D -o NAME,DISC-GRAN,DISC-MAX,DISC-ZERO
NAME     DISC-GRAN DISC-MAX DISC-ZERO
sda            512B       2G         0
nvme0n1          4K       2G         0

cr0x@server:~$ mount | egrep ' / |/data '
/dev/nvme0n1p2 on / type ext4 (rw,relatime)

Ce que cela signifie : Les périphériques supportent discard. Votre montage n’affiche pas discard ; ce n’est pas automatiquement mauvais. Le discard en ligne peut ajouter du jitter ; un fstrim périodique est souvent préférable.

Décision : Assurez-vous qu’un régime de trim existe (hebdomadaire fstrim ou équivalent). Les performances d’écriture soutenue sans TRIM sont un incident au ralenti.

Task 6: Run fstrim and observe behavior (jitter is a clue)

cr0x@server:~$ sudo fstrim -v /data
/data: 312.6 GiB (335657148416 bytes) trimmed

Ce que cela signifie : De l’espace a été trimé. Si cette commande prend « une éternité » ou provoque des pics de latence pour les locataires, votre stratégie de discard peut entrer en conflit avec votre charge.

Décision : Planifiez le trimming en période de faible trafic, ou validez le firmware du SSD/contrôleur. Si le trim cause des pauses notables, c’est une contrainte opérationnelle à prendre en compte.

Task 7: Spot filesystem-induced write latency (dirty ratios and writeback)

cr0x@server:~$ sysctl vm.dirty_ratio vm.dirty_background_ratio vm.dirty_expire_centisecs
vm.dirty_ratio = 20
vm.dirty_background_ratio = 10
vm.dirty_expire_centisecs = 3000

Ce que cela signifie : Le noyau peut bufferiser beaucoup de données dirty avant de forcer l’écriture. Cela peut produire des pics périodiques de latence lors du flush.

Décision : Si vous observez « toutes les N secondes l’appli se fige », envisagez d’ajuster les dirty ratios ou d’utiliser un regroupement côté application. NVMe peut masquer ce comportement ; il ne le guérira pas.

Task 8: Measure real device latency with fio (random read)

cr0x@server:~$ sudo fio --name=rr4k --filename=/dev/nvme0n1 --direct=1 --ioengine=libaio --iodepth=32 --rw=randread --bs=4k --numjobs=4 --runtime=60 --time_based --group_reporting
rr4k: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, ioengine=libaio, iodepth=32
...
read: IOPS=420k, BW=1641MiB/s (1720MB/s)(98.5GiB/60001msec)
   slat (nsec): min=650, max=220k, avg=2100.3, stdev=1800.1
   clat (usec): min=45, max=3200, avg=290.4, stdev=110.2
    clat percentiles (usec):
     |  1.00th=[  90],  5.00th=[ 130], 10.00th=[ 160], 50.00th=[ 270],
     | 95.00th=[ 480], 99.00th=[ 760], 99.90th=[1200], 99.99th=[2000]

Ce que cela signifie : Fortes IOPS de lecture aléatoire et latence tail respectable. Notez les percentiles : p99.9 ~1,2 ms. C’est le chiffre qui intéresse vos services à haute concurrence.

Décision : Si votre appli a besoin de haute concurrence en lecture aléatoire, NVMe est justifié. Si votre p99 de production est pire, le goulot est au-dessus du périphérique (système de fichiers, chiffrement, virtualisation, throttling) ou la charge n’est pas orientée lecture.

Task 9: Compare with SATA using the same fio profile (and watch the knee)

cr0x@server:~$ sudo fio --name=rr4k --filename=/dev/sda --direct=1 --ioengine=libaio --iodepth=32 --rw=randread --bs=4k --numjobs=4 --runtime=60 --time_based --group_reporting
rr4k: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, ioengine=libaio, iodepth=32
...
read: IOPS=68.5k, BW=268MiB/s (281MB/s)(16.1GiB/60004msec)
   clat (usec): min=80, max=18000, avg=1700.2, stdev=900.4
    clat percentiles (usec):
     |  1.00th=[ 220],  5.00th=[ 420], 10.00th=[ 520], 50.00th=[1500],
     | 95.00th=[3200], 99.00th=[5200], 99.90th=[9200], 99.99th=[15000]

Ce que cela signifie : Le SATA décroche fortement en IOPS et en latence tail à cette charge. Un p99.9 proche de 10 ms est l’endroit où les systèmes distribués commencent à « aider » avec des retries et empirent la situation.

Décision : Si votre service est sensible à la latence tail (la plupart le sont), et que vous exploitez de la concurrence, le SATA devient un mauvais choix par défaut pour le tier chaud.

Task 10: Test sync-heavy writes (the WAL/log reality check)

cr0x@server:~$ sudo fio --name=syncwrite --directory=/data --direct=1 --rw=write --bs=4k --numjobs=1 --iodepth=1 --fsync=1 --size=2G --runtime=60 --time_based --group_reporting
syncwrite: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, ioengine=psync, iodepth=1
...
write: IOPS=4800, BW=18.8MiB/s (19.7MB/s)(1.10GiB/60001msec)
    clat (usec): min=110, max=32000, avg=205.3, stdev=410.2

Ce que cela signifie : Les écritures synchrones mono-thread sont limitées par la latence fsync, pas par la profondeur de queue. Même NVMe ne transforme pas fsync en friandise gratuite ; il réduit juste la douleur si le disque et la pile sont bons.

Décision : Si vous êtes lié par le WAL, envisagez : périphérique de log séparé, group commit, réglage du checkpointing, ou un disque avec protection contre la perte de puissance. N’attendez pas que « plus de voies » règle des patterns de sync côté application.

Task 11: Check for device errors and media wear (quiet failures are still failures)

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i 'Reallocated|Pending|CRC|Power_On_Hours|Wear|Media'
Power_On_Hours          17342
UDMA_CRC_Error_Count    0
Reallocated_Sector_Ct   0
Current_Pending_Sector  0

cr0x@server:~$ sudo nvme smart-log /dev/nvme0n1
Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 43 C
available_spare                     : 100%
available_spare_threshold           : 10%
percentage_used                     : 7%
data_units_read                     : 123,456,789
data_units_written                  : 98,765,432
media_errors                        : 0
num_err_log_entries                 : 0

Ce que cela signifie : Pas d’erreurs évidentes ; l’usure NVMe est faible. Si vous voyez des erreurs média ou des entrées d’erreur qui augmentent, les incidents de performance sont souvent le premier acte.

Décision : Remplacez les disques suspects tôt. Le stockage échoue en deux phases : « latence étrange » puis « indisponible ». Vous voulez agir en phase une.

Task 12: Verify write cache settings (and whether you’re lying to yourself)

cr0x@server:~$ sudo hdparm -W /dev/sda

/dev/sda:
 write-caching =  1 (on)

Ce que cela signifie : Le cache d’écriture est activé. C’est acceptable avec des SSD, mais la durabilité dépend de la protection contre la perte d’alimentation et du firmware du disque.

Décision : Pour les bases qui tiennent à la durabilité, privilégiez les disques avec protection PLP. Si vous ne pouvez pas garantir cela, n’« optimisez » pas en faisant confiance à des caches que vous ne pouvez pas raisonner.

Task 13: Check device mapper / encryption overhead (common in real estates)

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,MOUNTPOINT
nvme0n1        disk  931.5G
├─nvme0n1p1    part    512M /boot
└─nvme0n1p2    part    931G
  └─cryptdata  crypt   931G /data

cr0x@server:~$ sudo cryptsetup status cryptdata
/dev/mapper/cryptdata is active.
  type:    LUKS2
  cipher:  aes-xts-plain64
  keysize: 512 bits
  device:  /dev/nvme0n1p2
  sector size:  512
  offset:  32768 sectors
  size:    1953499136 sectors
  mode:    read/write

Ce que cela signifie : Le chiffrement est dans le chemin. Sur des CPU modernes avec AES-NI, c’est souvent acceptable, mais cela peut devenir lié CPU à haut débit, et ajouter de la variance de latence.

Décision : Si les chiffres NVMe déçoivent, vérifiez l’utilisation CPU pendant fio. Si le crypto est le goulot, « acheter un disque plus rapide » devient « acheter du CPU ou tuner le chiffrement ».

Task 14: Find which process is causing I/O pressure (so you can stop blaming “the disk”)

cr0x@server:~$ sudo iotop -o -b -n 3
Total DISK READ: 12.34 M/s | Total DISK WRITE: 145.67 M/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN  IO>    COMMAND
 9123 be/4  postgres    1.23 M/s   80.12 M/s  0.00 % 45.00 % postgres: checkpointer
 9050 be/4  postgres    0.00 B/s   30.45 M/s  0.00 % 20.00 % postgres: walwriter
 7711 be/4  root        0.00 B/s   25.10 M/s  0.00 % 12.00 % tar -cf /backup/data.tar /data

Ce que cela signifie : Le checkpointing et les sauvegardes génèrent une charge d’écriture significative. Ce n’est pas une « lenteur mystérieuse du stockage » ; c’est votre système qui fait exactement ce que vous lui avez demandé, bruyamment.

Décision : Replanifiez les sauvegardes, ajustez le checkpointing DB, ou isolez les charges sur des périphériques différents. N’achetez pas du NVMe juste pour laisser tar se battre avec votre base à midi.

Blague 2 : Acheter du NVMe pour corriger un job de sauvegarde bruyant, c’est comme acheter un ascenseur plus rapide parce que quelqu’un maintient la porte ouverte.

Trois mini-histoires d’entreprise (anonymisées, plausibles et douloureuses)

1) L’incident causé par une mauvaise hypothèse : « Le SSD SATA est essentiellement du NVMe pour notre appli »

L’entreprise migrerait des vieux disques rotatifs vers des SSD. L’histoire d’achat était propre : les SSD SATA étaient moins chers, disponibles et « suffisamment rapides ». Quelqu’un a lancé un test rapide de débit séquentiel, vu des centaines de MB/s, et approuvé. L’équipe plateforme a déployé une flotte de réplicas de base sur SATA.

Pendant deux semaines, tout semblait bien — parce que le trafic était faible. Puis une campagne marketing a frappé, et la concurrence de lecture a augmenté. Le premier symptôme n’a pas été des alertes disque. Ce fut la latence p99 des API qui a bondi, suivie d’une vague de storms de retries entre services. Quelques workers basés sur des queues ont commencé à expirer et remettre les jobs en file. Le système n’est pas tombé d’un coup ; il s’est dégradé lentement et cruellement, comme une réunion qui aurait dû être un e-mail.

Sur les hôtes de DB, le CPU était bas. La mémoire avait de la marge. Le réseau semblait normal. Mais iostat montrait le périphérique SATA bloqué à 100 % d’utilisation avec await en dizaines de millisecondes. L’on-call a d’abord soupçonné un déploiement applicatif. Ils ont rollbacké. Rien n’a changé.

La cause racine était la mauvaise hypothèse : « SSD c’est SSD ». La charge était des petites lectures aléatoires avec assez de parallélisme pour saturer le SATA. La latence tail a monté, l’application a retried, et la charge s’est amplifiée. Quand ils ont re-lancé le benchmark avec un fio réaliste (random read, concurrence, percentiles), l’écart entre SATA et NVMe n’était pas subtil ; c’était la différence entre stable et chaotique.

Ils ont déplacé les réplicas les plus chauds sur NVMe, gardé le SATA pour les réplicas froids et les jobs batch, et ajouté un test de charge standard à l’acceptation matériel. La vraie leçon n’était pas « toujours acheter NVMe ». C’était « toujours tester la charge que vous réalisez réellement ».

2) L’optimisation qui a mal tourné : « Activons discard en ligne partout »

Une autre entreprise avait une flotte de SSD qui perdaient lentement en performance d’écriture sur des mois. Quelqu’un a identifié correctement que le trim ne se faisait pas de manière fiable. La solution la plus rapide semblait être de monter les systèmes avec discard pour que le noyau fasse le TRIM en ligne.

Ça a marché — en partie. Les performances soutenues se sont améliorées. Mais la variance de latence s’est aggravée. Sur certains hôtes, toutes les quelques minutes la latence p99 grimpait, et le « chemin rapide » de l’application subissait parfois des pauses de 100 ms. Les rapports d’incident étaient exaspérants parce que les pics étaient courts et le système revenait à la normale avant que quiconque puisse capturer un profil propre.

Ils ont fini par corréler les pics avec l’activité de discard. Le discard en ligne introduisait du travail supplémentaire dans le chemin I/O et interagissait mal avec leur charge mixte : beaucoup de petites écritures plus des suppressions périodiques massives. Le firmware du périphérique s’en sortait, mais le résultat opérationnel était du jitter.

La correction a été ennuyeuse : retirer discard des options de montage, planifier fstrim pendant des fenêtres de faible trafic, et surveiller la durée du trim. Les performances sont restées bonnes et les pics de latence ont disparu. L’« optimisation » n’était pas fausse en principe ; elle était mauvaise en production car ils avaient optimisé pour le débit soutenu au prix de la latence tail.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : « On baseline la latence avant les upgrades »

Celle-ci n’est pas dramatique, et c’est pourquoi ça a marché. Une équipe opérant une plateforme de conteneurs avait pour routine : avant les upgrades noyau, exécuter une petite suite de tests stockage sur un nœud canari. Pas des benchmarks héroïques — juste quelques profils fio représentant leurs PV communs, plus une vérification rapide de l’état du lien PCIe et du SMART NVMe.

Un week-end, les chiffres du canari étaient hors norme. Les percentiles de latence en lecture aléatoire étaient pires, et le débit avait chuté. L’application n’avait pas changé. Le matériel n’avait pas changé. Le seul changement était le nouveau noyau. L’équipe a stoppé le déploiement, enquêté, et trouvé qu’un paramètre de pilote/module avait modifié le comportement pour leurs NVMe d’une manière qui augmentait la latence sous concurrence.

Parce qu’ils avaient des baselines, la régression était évidente. Parce qu’ils ont exécuté les tests avant le rollout, le périmètre impacté fut un seul nœud. Ils ont ajusté la configuration, confirmé que les métriques retournaient à la baseline, puis ont poursuivi le déploiement en confiance.

Personne en dehors de l’équipe ne l’a remarqué. C’est le but. La pratique « ennuyeuse » n’était pas d’acheter un meilleur matériel. C’était de traiter la performance stockage comme un contrat et de la vérifier en continu.

Playbook de diagnostic rapide

Si vous avez 15 minutes pour trouver le goulot, faites ceci dans l’ordre. Ne soyez pas malin. Soyez rapide et correct.

Première étape : prouver que c’est la latence stockage (pas le CPU, pas le réseau, pas des locks)

• Vérifiez la latence p95/p99 applicative et les taux d’erreur. Cherchez des retries/timeouts.
• Sur l’hôte : iostat -xz 1 et surveillez %util et await.
• Vérifiez vmstat 1 pour un wa élevé (iowait) et la file d’attente run.

Deuxième étape : trouvez quel périphérique et quel processus

• lsblk pour cartographier montages → périphériques.
• iotop -o pour identifier les plus gros writers/readers.
• pidstat -d 1 si vous avez besoin des taux I/O par processus sans outils interactifs.

Troisième étape : décidez si c’est saturation, mauvaise config ou dégradation

• Saturation : %util proche de 100 %, await en hausse, aqu-sz profond. Corrigez en déplaçant la charge, ajoutant des périphériques ou en réduisant les I/O.
• Mauvaise configuration : scheduler inadapté, mauvaises options RAID, throttling virtualisation, overhead chiffrement, options de montage. Corrigez la pile.
• Dégradation : erreurs SMART, logs d’erreur NVMe, throttling thermique, lien PCIe degradé. Remplacez ou corrigez le hardware/firmware.

Quatrième étape : validez avec un test fio ciblé

Lancez un profil fio court correspondant à votre douleur : lecture aléatoire sous concurrence ? écritures sync ? mix 70/30 ? Utilisez --direct=1 et capturez les percentiles. Si le test périphérique est bon mais la prod est mauvaise, le goulot est au-dessus de la couche bloc.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: “NVMe is installed but performance looks like SATA”

Cause racine : lien PCIe rétrogradé (x1/x2, GT/s inférieur), mauvais slot, économies d’énergie BIOS, ou lane partagée chipset.

Correction : Vérifiez lspci -vv pour l’état du lien ; déplacez le périphérique vers un slot attaché au CPU ; ajustez le BIOS ; vérifiez câblage/risers ; retestez.

2) Symptom: “fio looks amazing, production is still slow”

Cause racine : le benchmark a utilisé le page cache ou une charge irréaliste ; la production est sync-heavy ou mixte ; throttling de virtualisation ou limites cgroup.

Correction : Utilisez --direct=1, taille > RAM, et une charge correspondant à votre appli. Vérifiez les limites I/O cgroup et les politiques hyperviseur.

3) Symptom: periodic latency spikes every few seconds/minutes

Cause racine : tempêtes de writeback (dirty ratios), rafales de journal filesystem, checkpoints DB, ou jitter dû au discard en ligne.

Correction : Ajustez les writeback, modifiez les paramètres de checkpoint DB, retirez discard et utilisez fstrim programmé, ou isolez les logs.

4) Symptom: high iowait but low disk utilization

Cause racine : vous attendez autre chose : stockage réseau, stalling firmware du contrôleur, couches device mapper, ou chemin de lock du système de fichiers surchargé.

Correction : Confirmez le chemin réel du périphérique. Pour le stockage réseau, mesurez la latence réseau et les stats côté serveur. Pour du local, vérifiez dmesg pour resets et erreurs.

5) Symptom: “We upgraded to NVMe and got worse p99 latency”

Cause racine : scheduler/réglages différents, throttling thermique, régression firmware, ou concurrence accrue révélant une contention applicative.

Correction : Vérifiez température et throttling ; comparez percentiles fio sous charge contrôlée ; limitez la concurrence ; révisez les réglages DB. Les disques plus rapides peuvent faire des locks le nouveau goulot.

6) Symptom: sustained write throughput collapses after a few minutes

Cause racine : épuisement du cache SLC et comportement d’état stable ; disque trop rempli ; TRIM absent ; disque grand public sous charge d’écriture entreprise.

Correction : Laissez de l’espace libre (overprovisioning), assurez le trim, choisissez un SSD entreprise avec endurance et performance d’écriture stable, exécutez des tests plus longs avant d’acheter.

Checklists / plan étape par étape

Étape par étape : choisir NVMe vs SATA pour un nouveau service

1. Classifiez la charge : OLTP DB, ingestion de logs, hôte VM, analytics, stockage objet.
2. Choisissez 2–3 profils fio qui y correspondent (taille de bloc, mix, concurrence, sémantiques sync).
3. Exécutez sur le matériel candidat avec le même noyau, système de fichiers, chiffrement et options de montage que vous déploierez.
4. Enregistrez les percentiles (p95/p99/p99.9), pas seulement IOPS/BW.
5. Trouvez le genou : augmentez iodepth/numjobs jusqu’à ce que la latence tail saute. C’est la frontière de votre région d’exploitation sûre.
6. Mappez les résultats aux SLO : si votre appli exige p99 < 5 ms sous charge, et que le SATA vous donne 20 ms p99.9 à la concurrence réaliste, la décision est prise.
7. Décidez des niveaux : NVMe pour les données chaudes et les logs ; SSD SATA pour le chaud-froid, sauvegardes, batch, réplicas.
8. Opérationnalisez : tests de baseline sur canaris, surveillance SMART/NVMe log, calendrier de trim, gestion firmware.

Étape par étape : rétrofiter un système lent existant

1. Exécutez iostat -xz 1 et iotop -o pendant la fenêtre d’incident.
2. Cartographiez le mount chaud au périphérique avec lsblk.
3. Vérifiez les jobs en arrière-plan (backup, compaction, scrubs).
4. Vérifiez la santé du périphérique (SMART/NVMe logs) et l’état du lien PCIe (NVMe).
5. Exécutez un test fio ciblé correspondant au pattern suspecté sur le périphérique affecté.
6. Si fio est bon mais la prod est mauvaise : regardez au-dessus de la couche bloc (système de fichiers, chiffrement, config DB, cgroups, hyperviseur).
7. Appliquez le plus petit changement qui enlève le goulot : déplacer le WAL, isoler les backups, régler les checkpoints, ou migrer les données chaudes sur NVMe.
8. Retestez et enregistrez une baseline pour que le prochain incident soit plus court.

Checklist opérationnelle : quoi surveiller en continu

• Latence p95/p99 aux frontières de service ; taux de retries.
• await disque, %util, taille de queue, et mix lecture/écriture par périphérique.
• SMART NVMe : température, pourcentage utilisé, erreurs média, entrées de log d’erreur.
• Espace libre système de fichiers et succès des trims.
• Timing des jobs en arrière-plan : sauvegardes, compactions, scrubs.

FAQ

1) Is NVMe always faster than SATA SSD?

Pas toujours de la façon qui compte pour vous. Pour de faibles niveaux de concurrence et des charges simples, le SATA peut être « assez rapide ». Sous I/O aléatoire parallèle et charges mixtes, NVMe gagne généralement — surtout sur la latence tail.

2) Why does my sequential benchmark show small differences, but my database feels much faster on NVMe?

Parce que les bases de données sont rarement séquentielles. Elles font de petits reads/writes aléatoires, des écritures sync pour les logs, et des patterns d’accès mixtes. Le modèle de queueing de NVMe et son overhead réduit aident là où la base travaille réellement.

3) What fio options prevent me from benchmarking the page cache?

Utilisez --direct=1, et assurez-vous que la taille du test dépasse la RAM si vous utilisez un fichier. Pour les périphériques bruts, utilisez le chemin du device et faites attention à ne pas écraser des données réelles.

4) What queue depth should I test?

Testez une plage : 1, 4, 16, 32, 64—plus la concurrence réaliste (numjobs). Vous cherchez le genou où les percentiles de latence s’effondrent. Ce genou est souvent la limite de capacité qui compte en production.

5) Can SATA SSD be the right choice in production?

Oui : tiers chaud-froid, services majoritairement en lecture avec faible concurrence, caches, réplicas, pipelines batch et staging de sauvegarde. C’est aussi pertinent quand le goulot est ailleurs et que vous l’avez prouvé par mesure.

6) Do I need power-loss protection (PLP) on NVMe?

Si vous tenez aux garanties de durabilité (bases, systèmes de fichiers avec sémantiques strictes), la PLP est fortement recommandée. Sans elle, vous pouvez compter sur des caches volatils plus que vous ne le pensez.

7) Why does performance get worse when the disk is almost full?

Les SSD ont besoin de blocs libres pour le garbage collection et le wear leveling. Moins d’espace libre implique plus de copies internes et une amplification d’écriture plus élevée. Gardez de la marge et trimmez correctement.

8) Is it worth separating database WAL/logs onto NVMe while data stays on SATA?

Souvent oui. Le WAL et les logs sont sensibles à la latence et sync-heavy. Mettre les logs sur un périphérique plus rapide et à latence plus faible peut améliorer la latence de commit et réduire la contention. Testez- le — n’en faites pas une hypothèse.

9) How do I know if I’m CPU-bound due to encryption rather than disk-bound?

Exécutez fio et surveillez l’utilisation CPU. Si le débit plafonne tandis que le disque n’est pas occupé et que le CPU est élevé dans les chemins kernel/crypto, vous êtes lié CPU. Envisagez des CPU plus rapides, du tuning, ou un offload matériel selon votre environnement.

Prochaines étapes pratiques

Faites trois choses cette semaine :

1. Décrivez votre charge en une phrase : taille de bloc, mix lecture/écriture, exigences de sync, et concurrence attendue. Si vous ne pouvez pas la décrire, vous ne pouvez pas acheter le bon matériel.
2. Créez une petite suite fio (2–4 jobs) et exécutez-la sur un SSD SATA et un NVMe dans votre environnement. Capturez les latences p95/p99/p99.9.
3. Définissez une baseline et protégez-la : exécutez la suite sur un canari avant les changements noyau/firmware. Les régressions stockage sont sournoises ; les baselines les rendent bruyantes.

Si vous construisez des services sensibles à la latence ou exploitez des hôtes multi-tenant, choisissez NVMe par défaut pour le chemin chaud et justifiez SATA seulement si la mesure le prouve. Si vous gérez des tiers chaud-froid, des sauvegardes ou des charges lecture-peu concurrentes, le SATA peut être un choix rationnel et économique. Quoi qu’il en soit, le test de charge met fin au débat — et vous évite d’expédier un incident stockage sous prétexte d’une fonctionnalité.