Migration vers « SSD premium » : latence requêtes divisée par deux le jour J. Trois semaines après, retour à la lenteur. Les burst credits du volume VPS sont épuisés en permanence — 300 IOPS plafond invisible sur la page prix.
IOPS explique la différence entre disque « rapide au feeling » et disque tenable 24/7.
Random vs sequential
Marketing cite souvent sequential GB/s. Votre DB fait random 4K–8K. Mesurez ce qui compte.
| Pattern | Outil type | Sensibilité |
|---|---|---|
| Random read/write | OLTP | IOPS + latence p99 |
| Sequential | Backup, ETL | MB/s |
| Sync write | WAL, fsync | Latence commit |
Burst et credits
T2/AWS gp2/gp3, VPS cheap : burst puis throttle. iostat -x 1 : %util 100 + await ms élevé = saturation.
Cloud : lisez baseline vs burst IOPS contractuelles.
Impact applicatif
Postgres : checkpoint, autovacuum. MySQL : innodb flush. Redis AOF fsync always = IOPS bound.
Symptôme : CPU idle, app slow, wa high.
Dimensionner
Estimez IOPS needed (monitor prod ou benchmark). Ajoutez marge 30 %. Séparez data/WAL si possible.
Object storage pour blobs — pas disque local pour photos user.
Comparer hébergeurs
Benchmark identique post-provision. Sustained 30 min, pas 30 s. Documentez pour renouvellement contrat.
Benchmark minimal
fio 4k randrw 70/30, iodepth 32, runtime 600s, direct=1. Note IOPS moyen et p99 latency.
Répéter sous charge app si possible.
Compare trois providers même price tier — écart 2× fréquent.
DB prod : séparer volume data et WAL si provider le permet.
Renégociez avec chiffres, pas avec « ça rame ».
Tuning applicatif avant upgrade disk
Postgres : checkpoint tuning, random_page_cost SSD. MySQL : innodb flush log at transaction commit vs 2 — tradeoff durabilité/IOPS.
Upgrade disk sans tuning app = déception répétée.
Elasticsearch sur disque network attaché sans IOPS provisioned : cluster yellow permanent — dimensionnez ou local SSD.
Small random writes fsync-heavy : NVMe marketing ≠ fsync latency under load.
Cloud volume types
gp3 IOPS provisioned independently size — upgrade IOPS sans resize GB.
Local NVMe instance store ephemeral : IOPS élevé mais perte si stop instance — WAL on network block with IOPS.
Monitoring : iostat await p99 alert >20ms sustained.
Synthèse opérationnelle
IOPS sustained mixed read/write déterminent ressenti DB — pas peak marketing NVMe. fio 600s, iostat await, séparer WAL/data si possible. Upgrade disk sans tuning checkpoint = déception répétée.
Compare hosts même benchmark script avant signature.
Avant achat premium disk
Baseline fio actuel archivé. Upgrade tier. Re-fio 600s même script. Compare % gain vs coût +30%. Si gain <15% : tuning app d'abord.
Document decision memo finance — évite cycle upgrade disk annuel sans preuve.
Renégociation
PDF benchmark joint renouvellement — leverage data.
Revue index
Avant upgrade tier disk, slow query log une semaine plus EXPLAIN top dix. Index manquant = fix gratuit IOPS.
Suivi opérationnel
Graph IOPS dans dashboard exec monthly — visibilité budget. Corrélation facture cloud et IOPS provisioned. Postgres pg_stat_statements top ten review monthly — index before invoice argument. Documentez les écarts entre promesse hébergeur et mesure terrain dans la revue trimestrielle.
Poursuite trimestrielle
Graph IOPS dans dashboard exec monthly — visibilité budget. Corrélation facture cloud et IOPS provisioned. Postgres pg_stat_statements top ten review monthly — index before invoice argument. Documentez les écarts entre promesse hébergeur et mesure terrain dans la revue trimestrielle.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
fio et tuning
fio 600s avant tier premium. <15% gain → tuning Postgres d'abord. PDF renewal. Data/WAL split.
Symptômes : iowait idle CPU, checkpoints longs, queue depth >10.
Décider et avancer sans angle mort
- Benchmark fio identique — 4k randrw 70/30, iodepth 32, 600 s, direct=1 sur volume idle puis sous charge app.
- Comparer trois providers même tier prix — écart 2× fréquent ; archivez PDF pour renouvellement.
- Séparer data et WAL — si le provider le permet sur PostgreSQL prod.
- Lire sustained mixed IOPS — pas le burst marketing dix secondes.
- Renégocier avec chiffres — pas « ça rame » sans iowait et queue depth.
Choisissez tier stockage via l'annuaire, le comparateur et nos guides bases de données.
Questions fréquentes
IOPS vs débit MB/s ?
IOPS = opérations 4K random/s. MB/s = sequential. DB OLTP = IOPS random ; backup/video = débit.
Pourquoi chiffres marketing irréalistes ?
Burst court, 4K read idéal, local cache — sustained mixed read/write prod est bien plus bas.
Comment tester ?
fio --rw=randrw --bs=4k --iodepth=32 sur volume idle ET sous charge app. Comparez providers.
Symptômes sous-dimensionnement ?
iowait élevé, checkpoint long Postgres, commit latency MySQL, queue depth disque > 10 sustained.
Demandez le plafond IOPS sustained au support avant le prochain Black Friday — le burst ne couvre pas huit heures de pic.