Quand on parle de performance des systèmes de stockage, on entend souvent le terme IOPS. Mais qu'est-ce que cela signifie vraiment ? Les IOPS (Input/Output Operations Per Second) désignent le nombre d’opérations d’entrée/sortie qu’un système de stockage peut effectuer en une seconde. En d'autres termes, c'est une mesure clé pour évaluer la rapidité d'accès aux données.
C'est quoi les IOPS ?
Section intitulée « C'est quoi les IOPS ? »Les IOPS (Input/Output Operations Per Second) mesurent la capacité d’un système de stockage à traiter les opérations d’entrée/sortie en une seconde. On Sur un disque mécanique, où une seule opération est servie à la fois, on les estime à partir du temps que prend cette opération. Les durées étant en millisecondes, on divise donc 1 000 par leur somme :
IOPS = 1000 / (latence moyenne + temps de rotation + temps de transfert) durées exprimées en millisecondesChaque élément de la formule influence directement les IOPS d'un disque mécanique. Voici une explication des termes.
- Latence moyenne : La latence moyenne correspond au temps qu’un système met pour démarrer une opération d’entrée/sortie. Elle inclut le délai pour accéder au disque et envoyer une réponse. Une latence faible améliore les
- Temps de rotation : Le temps de rotation s’applique aux disques mécaniques (HDD). C’est le temps nécessaire pour que les données se positionnent sous la tête de lecture.
- Temps de transfert : Le temps de transfert est le temps pour lire ou écrire les données une fois qu’elles sont accessibles. Il dépend de la vitesse du disque et de la taille des blocs.
La formule montre que pour augmenter les IOPS, il faut réduire la latence, le temps de rotation (pour les HDD) et le temps de transfert. C’est pourquoi les SSD et NVMe, qui ont des temps très faibles pour ces facteurs, offrent des performances bien supérieures aux HDD traditionnels.
Exemple de calcul - HDD vs SSD :
Prenons deux exemples pour illustrer le calcul théorique.
- HDD 7 200 RPM :
- Latence : 4 ms
- Temps de rotation moyen : 4,17 ms
- Temps de transfert pour 4 Ko : 0,005 ms
temps par opération = 4 + 4,17 + 0,005 = 8,175 ms = 0,008175 sIOPS = 1 / 0,008175 ≈ 122 IOPSLa conversion d'unité n'est pas un détail de présentation. La formule donne des opérations par seconde ; si vous divisez 1 par une durée exprimée en millisecondes, vous obtenez 0,12 et non 122, soit un facteur 1 000. C'est l'erreur la plus commune de ce calcul, et elle passe inaperçue parce que le résultat attendu est connu d'avance.
- SSD SATA :
- Latence : 0,1 ms
- Temps de rotation : 0 ms (pas de plateaux mécaniques)
- Temps de transfert pour 4 Ko : 0,002 ms
temps par opération = 0,1 + 0 + 0,002 = 0,102 ms = 0,000102 sIOPS = 1 / 0,000102 ≈ 9 800 IOPSCes deux calculs restent théoriques et mono-file : ils décrivent un disque sollicité par une seule requête à la fois. Un disque réel, et plus encore un volume cloud, en traite plusieurs en parallèle, et c'est précisément ce que la mesure qui suit va montrer.
Comment mesurer les IOPS réels ?
Section intitulée « Comment mesurer les IOPS réels ? »Le calcul théorique des IOPS donne une estimation idéale des performances, mais pour connaître les IOPS réels de votre système, il faut effectuer des tests pratiques dans des conditions proches de l’environnement d’exploitation. Ces tests prennent en compte les charges de travail, les configurations matérielles et les contraintes logicielles.
Plusieurs outils sont disponibles pour évaluer les IOPS réels. Voici les plus courants :
dd(pour des tests simples, mais limités).fio: L’un des outils les plus flexibles pour tester les performances des disques.
Mesure avec dd
Section intitulée « Mesure avec dd »Si vous souhaitez une méthode rapide et simple, utilisez la commande dd. Bien
que moins précise, elle peut donner une idée des performances.
dd if=/dev/zero of=/tmp/testfile bs=4k count=100000 oflag=direct
100000+0 records in100000+0 records out409600000 bytes (410 MB, 391 MiB) copied, 3,94857 s, 104 MB/s- if=/dev/zero : Génère des données nulles pour l’écriture.
- of=/tmp/testfile : Spécifie le fichier de sortie pour les tests d’écriture.
- bs=4k : Définit la taille des blocs (4 Ko ici).
- count=100000 : Nombre de blocs à écrire.
- oflag=direct : Évite la mise en cache pour des résultats plus réalistes.
Le résultat indique le débit, mais vous pouvez estimer les IOPS en divisant le débit total par la taille des blocs.
Le résultat de votre commande dd montre les performances suivantes :
- Nombre total d'opérations : 100 000 blocs de 4 Ko ont été écrits.
- Taille totale transférée : 409 600 000 octets, soit environ 410 Mo.
- Temps total : 3,94857 secondes.
- Débit : 104 Mo/s.
Pour estimer les IOPS réels, on peut utiliser la formule suivante :
IOPS = (nombre de blocs transférés) / (temps total)Ici, chaque bloc est de 4 Ko :
IOPS = 100 000 / 3,94857 ≈ 25 330 IOPSLa taille des blocs joue un rôle importants dans les IOPS et le débit global.
Voici comment cela impacte les performances :
- Petits blocs (4 Ko, 8 Ko) : Augmentent le nombre d’opérations possibles, ce qui booste les IOPS, mais au prix d’une plus grande charge CPU.
- Grands blocs (64 Ko, 128 Ko) : Réduisent les IOPS, mais augmentent le débit, idéal pour les transferts séquentiels de gros fichiers.
Vous pouvez tester avec dd différentes tailles de blocs pour voir l’impact sur
vos résultats. Par exemple :
dd if=/dev/zero of=/tmp/testfile bs=64k count=10000 oflag=directCe qui donne :
IOPS = 10 000 / 2,12744 ≈ 4 700 IOPSMesure avec fio
Section intitulée « Mesure avec fio »fio est l'outil de référence, et il est très facile de lui faire produire un
chiffre qui ne veut rien dire. Trois options décident de la validité de la
mesure, et les oublier donne des résultats qui semblent plausibles tout en
mesurant autre chose que ce que l'on croit.
| Option | Sans elle | Pourquoi c'est indispensable |
|---|---|---|
--ioengine=libaio | fio utilise psync, synchrone | avec un moteur synchrone, iodepth est plafonné à 1 : vous demandez 16 requêtes en vol, vous en obtenez une |
--direct=1 | les lectures passent par le cache du système | vous mesurez la vitesse de la mémoire, pas celle du disque |
--size adapté | numjobs fichiers de cette taille sont créés | quatre jobs de 1 Go réclament 4 Go libres, sinon l'un d'eux meurt en ENOSPC |
Le test correct
Section intitulée « Le test correct »fio --name=randread --rw=randread --bs=4k --size=256M --numjobs=4 \ --iodepth=16 --ioengine=libaio --direct=1 \ --runtime=15 --time_based --group_reportingRelevé sur un poste de travail à disque NVMe, en septembre 2026 :
randread: (g=0): rw=randread, bs=(R) 4096B-4096B, ioengine=libaio, iodepth=16 read: IOPS=605k, BW=2365MiB/s (2480MB/s)(34.6GiB/15001msec) clat percentiles (usec): | 1.00th=[ 63], 5.00th=[ 71], 10.00th=[ 97], 20.00th=[ 147], | 50.00th=[ 318], 70.00th=[ 478], 90.00th=[ 799], 95.00th=[ 988], | 99.00th=[ 1369], 99.50th=[ 1500], 99.90th=[ 1811], 99.95th=[ 1942], IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%Vérifiez toujours la dernière ligne avant de croire la première. Ici
16=100.0% atteste que la profondeur demandée a bien été tenue ; la mesure de
605 000 IOPS est donc exploitable.
Lire les percentiles plutôt que la moyenne
Section intitulée « Lire les percentiles plutôt que la moyenne »La latence moyenne ne dit rien de l'expérience réelle. Ce sont les percentiles qui comptent, et fio les donne en microsecondes.
| Percentile | Valeur relevée | Ce qu'il signifie |
|---|---|---|
| 50e | 318 µs | la moitié des requêtes sont plus rapides |
| 95e | 988 µs | une requête sur vingt dépasse cette durée |
| 99e | 1 369 µs | une sur cent, soit plusieurs par seconde à ce débit |
| 99,95e | 1 942 µs | six fois la médiane |
Une page web qui déclenche vingt requêtes disque attend le plus lent des vingt. C'est pourquoi une infrastructure se juge sur son 95e ou son 99e centile : la moyenne masque exactement ce que vos utilisateurs ressentent.
Mesurer le débit, un autre profil
Section intitulée « Mesurer le débit, un autre profil »Les IOPS et le débit ne se mesurent pas avec le même test. Petits blocs et accès aléatoire donnent des IOPS ; gros blocs et accès séquentiel donnent des mégaoctets par seconde.
fio --name=seqread --rw=read --bs=1M --size=512M --numjobs=2 \ --iodepth=8 --ioengine=libaio --direct=1 \ --runtime=15 --time_based --group_reporting read: IOPS=4700, BW=4700MiB/s (4928MB/s)(68.9GiB/15004msec)Le même matériel qui affichait 605 000 IOPS n'en fait plus que 4 700, et c'est normal : chaque opération transporte 1 Mo au lieu de 4 Ko. Comparer deux chiffres d'IOPS obtenus avec des tailles de bloc différentes n'a aucun sens, et c'est l'erreur la plus fréquente quand on lit des tableaux comparatifs.
Combien d'IOPS un volume cloud rend-il vraiment ?
Section intitulée « Combien d'IOPS un volume cloud rend-il vraiment ? »Un volume cloud n'a pas une performance, il a un plafond contractuel, et l'atteindre demande de lui envoyer assez de requêtes en parallèle. C'est la différence la plus importante avec le disque de votre poste, et elle ne se voit qu'en faisant varier la profondeur de file.
Le relevé ci-dessous a été fait le 10 septembre 2026 sur un volume Block
Storage Scaleway de 20 Go créé avec perf-iops=5000, attaché à une instance
DEV1-S en fr-par-1, avec fio 3.28. Les mesures portent sur le
périphérique brut, sans système de fichiers, en lecture aléatoire de 4 Ko
pendant 30 secondes par palier. Lisez le tableau de haut en bas : c'est la
progression qui enseigne, pas une ligne isolée.
| Profondeur de file | IOPS | p50 | p95 | p99 |
|---|---|---|---|---|
psync, iodepth=16 demandé, 1 obtenu | 2 126 | 387 µs | 619 µs | 1 434 µs |
libaio, iodepth=1 | 2 153 | 367 µs | 569 µs | 1 057 µs |
libaio, iodepth=2 | 4 510 | 354 µs | 545 µs | 1 090 µs |
libaio, iodepth=4 | 4 902 | 383 µs | 946 µs | 18 481 µs |
libaio, iodepth=8 | 5 150 | 412 µs | 1 319 µs | 36 962 µs |
libaio, iodepth=16 | 5 038 | 444 µs | 41 681 µs | 43 778 µs |
libaio, iodepth=32 | 5 041 | 594 µs | 45 875 µs | 46 400 µs |
libaio, iodepth=64 | 5 041 | 1 139 µs | 47 448 µs | 47 972 µs |
Trois enseignements sortent de ce tableau, et aucun n'est visible sur une mesure unique.
Le mauvais benchmark coûte plus de la moitié du volume. La première ligne et la deuxième donnent le même résultat, 2 126 contre 2 153 IOPS : le moteur synchrone n'était pas le problème en soi, c'est la profondeur plafonnée à 1 qui l'était. Autrement dit, la commande fautive mesurait un volume à 5 000 IOPS et en annonçait 43 %. Quelqu'un qui prend cette décision sur ce chiffre paie un volume plus cher pour un besoin qu'il satisfaisait déjà.
Le plafond annoncé est réel, et il est atteint dès la profondeur 8. Les
5 150 IOPS relevés à iodepth=8 collent au plafond contractuel de 5 000, aux
arrondis de mesure près. Au-delà, la courbe est plate : 5 038, 5 041, 5 041.
Vous ne payez pas pour un maximum théorique, vous payez pour une limite que le
fournisseur applique, et il faut la solliciter correctement pour la constater.
Passé la saturation, le parallélisme n'achète plus que de la latence. C'est
le résultat le plus contre-intuitif : entre iodepth=8 et iodepth=64, les
IOPS ne bougent pas, mais le 99e centile passe de 37 ms à 48 ms et la
médiane est multipliée par près de trois. Empiler les requêtes sur un volume
déjà saturé ne le rend pas plus rapide, cela allonge la file d'attente. Une
application qui augmente son parallélisme d'accès disque pour « aller plus
vite » dégrade en réalité le temps de réponse qu'elle cherchait à améliorer.
Ce que cela change pour votre dimensionnement. Avant de payer un volume plus
performant, vérifiez d'abord que votre mesure sollicite le volume actuel à une
profondeur suffisante, puis regardez si votre application sait elle-même
paralléliser ses accès. Un volume à 15 000 IOPS ne servira à rien à une
application qui émet ses requêtes une par une : elle restera aux 2 000 IOPS que
sa latence lui impose, exactement comme la ligne iodepth=1 de ce tableau.
Qu’est-ce que le burst ?
Section intitulée « Qu’est-ce que le burst ? »Le burst est une fonctionnalité proposée par certains volumes de stockage dans le cloud qui permet de dépasser temporairement les performances normales (en termes de IOPS ou de débit). Cela s’avère particulièrement utile pour gérer des pics de charge ponctuels, lorsque les besoins en performance augmentent brièvement.
Lorsque les volumes ne sont pas utilisés à pleine capacité, ils accumulent des crédits de burst. Ces crédits s’accumulent avec le temps et peuvent être consommés lors de pics d’activité pour fournir des performances bien supérieures aux niveaux standards. Une fois ces crédits épuisés, le volume revient à ses performances normales, limitées à sa capacité de base.
Les avantages du burst
Section intitulée « Les avantages du burst »Le burst est particulièrement intéressant pour :
- Gérer les pics de charge : Il permet de répondre à des demandes élevées sans devoir surdimensionner le stockage.
- Optimiser les coûts : Les volumes avec burst sont généralement moins coûteux que ceux aux performances garanties.
- Charges imprévisibles : Idéal pour des besoins fluctuant, comme les démarrages de systèmes ou des analyses ponctuelles.
Les limitations
Section intitulée « Les limitations »Le burst a toutefois des contraintes :
- Pas de performances élevées en continu : Une fois les crédits épuisés, les performances redescendent au niveau de base.
- Surveillance nécessaire : Sans un suivi attentif, le risque de baisse soudaine de performance peut poser problème, surtout pour des applications critiques.
En résumé
Section intitulée « En résumé »Le burst est une solution idéale pour des charges de travail aux besoins irréguliers et pour gérer des pics courts. Cependant, pour des charges intensives et continues, il est préférable d’opter pour des volumes offrant des performances garanties, afin d’assurer une constance dans les traitements.
Les cas d’usage gourmands en IOPS
Section intitulée « Les cas d’usage gourmands en IOPS »Les applications gourmandes en IOPS nécessitent une infrastructure de stockage capable de gérer un grand nombre d’opérations d’entrée/sortie par seconde. Ces scénarios, souvent critiques pour les entreprises, exigent une performance constante et fiable pour éviter les goulots d'étranglement qui peuvent affecter la productivité ou l'expérience utilisateur.
Bases de données transactionnelles
Section intitulée « Bases de données transactionnelles »Les bases de données, comme les systèmes de gestion relationnels ou NoSQL, sont des exemples typiques d’applications gourmandes en IOPS :
- Transactions intensives : Les applications de type OLTP (Online Transaction Processing), comme les systèmes bancaires, nécessitent des lectures et écritures rapides et fréquentes.
- Accès aléatoire : La plupart des bases de données effectuent des opérations sur des blocs spécifiques, rendant les IOPS essentiels pour réduire la latence.
- Exigences de cohérence : Les bases de données doivent garantir que les écritures sont synchrones pour éviter la corruption des données.
Big Data et analytique en temps réel
Section intitulée « Big Data et analytique en temps réel »Les solutions de traitement Big Data nécessitent des capacités de stockage performantes pour répondre aux demandes massives de traitement et d'analyse :
- Collecte de données : Les pipelines qui agrègent des millions d'événements par seconde nécessitent un stockage rapide pour ne pas créer de files d’attente.
- Traitement analytique : Les moteurs comme Spark ou Hadoop bénéficient de IOPS élevés pour les tâches impliquant de gros volumes de données.
- Tableaux de bord en temps réel : Les solutions d'analyse en temps réel (ex : surveillance d’infrastructure ou suivi de métriques d’application) dépendent d’un accès rapide aux données pour une visualisation instantanée.
Machines virtuelles et conteneurs
Section intitulée « Machines virtuelles et conteneurs »Les environnements virtualisés ou conteneurisés, souvent déployés à grande échelle, génèrent des charges de travail exigeantes pour les IOPS :
- Machines virtuelles : Chaque VM a des besoins en IOPS pour ses propres opérations de lecture/écriture et une mauvaise configuration peut entraîner une concurrence excessive sur le stockage partagé.
- Conteneurs : Les orchestrateurs comme Kubernetes utilisent des volumes persistants pour stocker des données critiques, nécessitant des performances de stockage robustes.
Applications de streaming multimédia
Section intitulée « Applications de streaming multimédia »Les plateformes de streaming vidéo ou audio génèrent un grand volume de lectures, notamment dans des scénarios où :
- Demande simultanée élevée : Lorsqu'un grand nombre d’utilisateurs accèdent aux mêmes fichiers multimédias en simultané.
- Caches et préchargements : Les serveurs de streaming utilisent souvent des caches pour réduire les lectures directes, mais nécessitent toujours des IOPS élevés pour gérer des fichiers volumineux.
Commerce en ligne et applications web
Section intitulée « Commerce en ligne et applications web »Les applications web et plateformes de commerce électronique reposent sur des IOPS élevés pour offrir une expérience utilisateur fluide :
- Requêtes utilisateurs : Les recherches de produits, les consultations de pages et les transactions créent une charge importante sur les bases de données.
- Pic de trafic : Les événements comme le Black Friday nécessitent une montée en charge rapide pour éviter des ralentissements ou des interruptions.
Systèmes de sauvegarde et de restauration
Section intitulée « Systèmes de sauvegarde et de restauration »Les sauvegardes régulières et les restaurations en cas de panne exigent des performances en IOPS pour réduire les temps d’inactivité :
- Sauvegardes incrémentales : Nécessitent un grand nombre de lectures et écritures rapides pour ne pas perturber les systèmes en production.
- Restauration rapide : Lorsqu’un système critique tombe en panne, des IOPS élevés garantissent une récupération rapide des données.
Les cas d’usage gourmands en IOPS couvrent un large éventail d’industries et d’applications critiques. Pour ces scénarios, une infrastructure bien configurée et capable de gérer un grand nombre d’opérations est essentielle pour garantir des performances fiables et éviter les interruptions. Planifier et surveiller ces charges de travail permet d’assurer un équilibre entre performance et coût.
Le choix des types et tailles de disques dans le cloud
Section intitulée « Le choix des types et tailles de disques dans le cloud »Le type et la taille des disques dans le cloud influencent directement les performances (IOPS et débit) et les coûts. Voici comment faire les bons choix.
Types de disques
Section intitulée « Types de disques »Attention à un abus de langage courant : on aligne souvent « HDD, SSD, NVMe » comme trois familles comparables, alors que les deux premiers désignent une technologie de support et le troisième une interface. Un disque NVMe est un SSD ; il se distingue par la façon dont il est relié à la machine, non par la manière dont il stocke.
| Ce que c'est | Ordre de grandeur en IOPS | Usage typique | |
|---|---|---|---|
| HDD | plateaux magnétiques en rotation | 100 à 200 | archivage, gros fichiers séquentiels |
| SSD (SATA) | mémoire flash, interface héritée du disque dur | quelques dizaines de milliers | usage général |
| SSD NVMe | même flash, interface directe sur le bus PCIe | des centaines de milliers | bases de données, charges critiques |
Ce qui sépare vraiment le SSD SATA du SSD NVMe, c'est le parallélisme que l'interface autorise : là où SATA sérialise les requêtes dans une file unique, NVMe en gère plusieurs milliers en parallèle. C'est exactement ce que mesure la profondeur de file de la section précédente.
Pourquoi la taille influence les performances
Section intitulée « Pourquoi la taille influence les performances »Sur certaines offres, les performances d'un volume dépendent de sa taille, et c'était même la règle générale il y a quelques années :
- IOPS liés à la capacité : le fournisseur accorde un nombre d'IOPS par gigaoctet alloué, par exemple 3 IOPS par Go. Agrandir le volume est alors le seul moyen d'aller plus vite.
- Débit lié à la capacité de la même façon.
Ce modèle recule. Beaucoup d'offres récentes permettent de choisir la capacité, les IOPS et le débit indépendamment, et de payer chaque dimension séparément. Sur ces volumes, agrandir le disque pour gagner en performance revient à payer du stockage inutile alors qu'il suffisait de provisionner les IOPS.
Vérifiez donc, dans la grille tarifaire du type de volume que vous utilisez, laquelle des deux logiques s'applique avant de dimensionner. La réponse change complètement l'arbitrage.
Critères de choix
Section intitulée « Critères de choix »- Nature de la charge :
- Transactionnelles : SSD ou NVMe.
- Big Data : Disques à haut débit.
- Archivage : HDD.
- Optimisation des coûts :
- Sur une offre où les performances suivent la capacité, un volume plus grand apporte plus d'IOPS ; sur une offre à IOPS provisionnés, réglez les IOPS plutôt que la taille.
- Préférez des disques provisionnés uniquement pour des besoins constants.
Adaptez vos choix de disque (type et taille) à vos besoins spécifiques. Une bonne planification garantit des performances optimales sans exploser votre budget cloud.
Conclusion
Section intitulée « Conclusion »Les IOPS sont un indicateur clé pour évaluer les performances des systèmes de stockage. Comprendre leur fonctionnement et comment les mesurer est essentiel pour garantir des performances optimales, en particulier pour des charges de travail critiques. En choisissant les bons types et tailles de disques, vous pouvez optimiser vos coûts tout en offrant des performances fiables et évolutives.