Je comprends ce que sont les IOPS et le débit. Le débit mesure le flux de données en Mo/s et l'IOPS indique le nombre d'opérations d'E/S qui se produisent par seconde.
Ce que je ne comprends pas, c'est pourquoi de nombreux services de stockage montrent simplement les IOPS qu'ils fournissent. Je ne vois vraiment aucun scénario où je préférerais connaître les IOPS au lieu du débit.
Pourquoi les IOPS sont-elles importantes? Pourquoi AWS affiche-t-il principalement ses dispositions de stockage dans IOPS? Où les IOPS sont-ils plus pertinents que le débit (Mo/s)?
ÉDITER:
Certaines personnes se penchent sur cette question comme si je leur demandais ce qu'est l'accès aléatoire et comment il affecte les performances ou comment le disque dur et le SSD fonctionnent ... bien que je pense que ces informations soient utiles pour les personnes nouvelles dans le comportement de stockage, beaucoup d'attention est appliquée à cela et ce n'est pas le but de la question, la question concerne "Quelle nouvelle information est-ce que j'obtiens quand je vois un numéro IOPS, que je n'obtiendrais pas de débit (Mo/s ) nombre? "
Débit
Le débit est utile lorsque vous effectuez des opérations telles que la copie de fichiers. Lorsque vous faites presque n'importe quoi d'autre, ce sont des lectures et des écritures aléatoires sur le disque qui vous limiteront.
[~ # ~] iops [~ # ~]
Les IOPS spécifient généralement la taille de chaque paquet de données. Par exemple, AWS gp2 peut effectuer 10 000 IOPS avec une taille de charge utile de 16 Kio . Cela se multiplie à 160 Mo/s. Cependant, il est probablement peu probable que vous utilisiez la taille complète de la charge utile tout le temps, donc le débit réel sera probablement inférieur. NB KiB est 1024 octets, Ko est 1000 octets.
Parce que les IOPS spécifient une taille de paquet qui vous donne également un débit total. Alors qu'un débit élevé ne signifie pas que vous avez des IOPS élevés.
Scénarios
Considérez ces scénarios:
Bande LTO
Considérons un instant un système de sauvegarde sur bande. LTO6 peut faire 400 Mo/s, mais (je suppose ici) ne peut probablement même pas faire un IOP aléatoire, il pourrait être aussi bas que quelques secondes par IOP. D'un autre côté, il peut probablement faire beaucoup d'IOPS séquentiels, si un IOPS est défini comme la lecture ou l'écriture d'un paquet de données sur bande.
Si vous essayez de démarrer un système d'exploitation hors bande, cela prendra beaucoup de temps, si cela fonctionne. C'est pourquoi IOPS est souvent plus utile que le débit.
Pour comprendre un périphérique de stockage, vous voulez probablement savoir s'il s'agit d'IOPS aléatoires ou séquentiels et de la taille IO. De cela, vous pouvez dériver le débit.
[~ # ~] aws [~ # ~]
Notez qu'AWS publie à la fois les chiffres d'IOPS et de débit pour tous ses types de stockage, sur cette page . Le SSD à usage général (gp2) peut faire 10 000 IOPS de 16 Ko, ce qui donne un maximum de 160 Mo/s. Les IOPS provisionnés (io1) sont de 20 000 IOPS de 16 Ko, ce qui donne un maximum de 320 Mo/s.
Notez qu'avec les volumes gp2, vous obtenez 30IOPS par Go provisionné, donc pour obtenir 10000 IOPS, vous avez besoin d'un volume de 333,33 Go. Je ne me souviens pas si les volumes io1 ont une limitation similaire (cela fait un moment que je n'ai pas passé les examens associés où ce genre de chose est testé), mais je soupçonne qu'ils le font, et si c'est le cas, c'est probablement 60IOPS par Go.
Conclusion
Un débit séquentiel élevé est utile et, dans certains cas, est le facteur limitant des performances, mais un IOPS élevé est probablement plus important dans la plupart des cas. Bien entendu, vous avez toujours besoin d'un débit raisonnable, quel que soit l'IOPS.
Cela est dû au fait que le débit séquentiel n'est pas la façon dont la plupart des activités d'E/S se produisent.
Les opérations de lecture/écriture aléatoires sont plus représentatives de l'activité normale du système, et elles sont généralement liées par les IOPS.
Le streaming de porno de l'un de mes serveurs vers nos clients (ou le téléchargement sur notre CDN) est de nature plus séquentielle et vous verrez l'impact du débit là-bas.
Mais la maintenance de la base de données qui répertorie le porno et suit l'activité des utilisateurs à travers le site va être de nature aléatoire et limitée par le nombre de petites opérations d'E/S/seconde dont le stockage sous-jacent est capable.
J'ai peut-être besoin de 2 000 IOPS pour pouvoir exécuter les bases de données à une utilisation maximale, mais je ne peux voir qu'un débit de 30 Mo/s au niveau du disque en raison du type d'activité. Les disques sont capables de 1200 Mo/s, mais les IOPS sont la limitation dans l'environnement.
Il s'agit d'une façon de décrire le potentiel de capacité d'un système de stockage. Un SSD peut avoir la capacité de faire 80 000 IOPS et un débit de 600 Mo/s. Vous pouvez obtenir ce débit avec 6 disques 10k SAS réguliers, mais ils ne produiraient qu'environ 2000 IOPS.
Alors que la réponse d'ewwhite est tout à fait correct, je voulais fournir quelques chiffres plus concrets juste pour aider à mettre en perspective pourquoi la différence est importante.
Comme ewwhite l'a déjà correctement indiqué, la plupart des applications non diffusées en continu effectuent principalement des opérations de disque non séquentielles, c'est pourquoi les IOPS comptent en plus du débit de pointe théorique.
Lorsqu'un collègue et moi avons installé pour la première fois des disques SSD dans nos systèmes de développement pour remplacer les disques durs que nous utilisions auparavant, nous avons effectué des mesures de performances sur ceux-ci qui ont vraiment mis en évidence la raison pour laquelle cela importait:
Débit de lecture séquentiel: ~ 100 Mo/s
Débit de lecture non séquentiel (blocs de 2 000, IIRC): ~ 1 Mo/s
Débit de lecture séquentiel: ~ 700 Mo/s
Débit de lecture non séquentiel (2 000 blocs, IIRC): ~ 125 Mo/s
Comme vous pouvez le voir clairement dans l'exemple, le simple fait d'indiquer un débit maximal pour chaque appareil donnerait une image extrêmement inexacte de la façon dont ils se comparent. Le SSD n'est que 6 à 7 fois plus rapide que le disque dur lors de la lecture séquentielle de gros fichiers, mais il est 100 fois plus rapide lors de la lecture de petits morceaux de données à partir de différentes parties du disque. Bien sûr, avec les disques durs, cette limitation est largement due au fait que les disques durs doivent déplacer physiquement la tête r/w sur la piste souhaitée, puis attendre que les données souhaitées tournent sous la tête, tandis que les SSD n'ont pas de parties physiques à déplacer.
Nos temps de compilation se sont améliorés de façon beaucoup plus spectaculaire qu'une simple comparaison des débits maximums ne l'aurait suggéré. Les builds qui prenaient auparavant plus de 30 minutes se terminent désormais en une minute environ, car les E/S de disque lors d'une build de grande taille consistent en la lecture et l'écriture de nombreux fichiers source séparés qui ne sont pas individuellement très volumineux et peuvent être dispersés physiquement sur tout le disque .
En fournissant à la fois le débit et les numéros IOPS, vous pouvez avoir une bien meilleure idée de la façon dont une charge de travail donnée fonctionnera sur un périphérique de stockage donné. Si vous diffusez simplement de grandes quantités de données qui ne sont pas fragmentées, vous vous rapprocherez assez du débit maximal. Cependant, si vous effectuez de nombreuses petites lectures et/ou écritures qui ne sont pas stockées séquentiellement sur le disque, vous serez limité par les IOPS.
Pour effectuer une opération IO, le ou les disques doivent passer par une série d'opérations. Pour un disque dur mécanique, ils doivent le faire.
Le temps pris pour 3 dépend de la taille du bloc de données, mais le temps pris pour 1 et 2 est indépendant de la taille de la demande.
Le débit global et les chiffres IOP représentent des cas extrêmes. Les chiffres du débit global représentent le cas où chaque opération implique un grand bloc de données, de sorte que le lecteur passe la plupart de son temps à déplacer des données.
Le chiffre des IOP en titre représente le cas où les blocs de données sont très petits, de sorte que la majorité du temps est consacrée à rechercher les têtes et à attendre que les plateaux tournent.
Pour de nombreuses charges de travail, les blocs sont suffisamment petits pour que le nombre de blocs à transférer soit beaucoup plus important que la taille des blocs.
Répondre à votre question
"Quelle nouvelle information est-ce que j'obtiens quand je vois un numéro IOPS, que je ne verrais pas un numéro de débit (Mo/s)?"
directement, il s'agit de combien IO de la profondeur de file d'attente et de la taille de fichier spécifiées peuvent être stockées par seconde. Vous pouvez calculer le débit dans des conditions données à l'aide de la formule suivante:
IOPS * taille du fichier = débit
Les tests de stockage peuvent générer un nombre d'IOPS différent selon la taille du fichier et la profondeur de la file d'attente. À la profondeur de file d'attente = 1 ou 2, le contrôleur ne profitera pas de la mise en cache, tandis qu'à la profondeur de file d'attente 32, 256, 512, le nombre augmente plusieurs fois et ne change pas beaucoup. Avec une taille de fichier de 128 Ko, le nombre d'E/S par seconde pourrait être inférieur à celui des fichiers de 4 Ko, mais le débit - plus élevé.
La meilleure façon d'évaluer les performances d'un stockage consiste à rechercher des tests IOPS et de débit à plusieurs tailles de blocs et profondeurs de file d'attente différentes.
Il existe deux types de goulots d'étranglement que vous pouvez rencontrer sur IO volumes (ou IO en général en fait)).
Les performances réelles sont en effet mesurées pour inclure un composant basé sur le volume de données déplacé, mis à l'échelle par la bande passante disponible ou une taille de coût unitaire similaire, mais il existe également une surcharge associée aux demandes, qui est constante, qu'il s'agisse d'un disque, d'un réseau ou beaucoup d'autres choses.
coût unitaire * taille + frais généraux. l'équation d'une ligne.
Si le coût unitaire est grand ou que la taille est grande, il est logique de facturer en fonction de ces volumes, tels que les réseaux de téléphonie mobile, mais les frais généraux sont parfois beaucoup plus critiques.
Vous pouvez en faire vous-même une expérience simple, créer un répertoire avec quelques fichiers de 1 Go (ou tout ce qui est pratique, quelque chose d'aussi grand qu'il faut plusieurs secondes pour le lire/l'écrire), puis créer un dossier avec un million de fichiers de 100 octets (Remarque, c'est 0,1 Go de données), puis voyez ce qui se passe avec votre débit lorsque vous commencez à déplacer tout cela, par exemple entre différentes partitions/disques - vous obtiendrez des performances limitées par le débit pour les gros fichiers, et limitées par le nombre de fichiers pour les petits trucs.
Je suppose qu'Amazon connaît les deux modèles de charge et a simplement trouvé qu'un représentait mieux les capacités de leur infrastructure.
Il y a une limite à la taille d'un IOP qui est largement liée à la quantité que le magasin peut transférer dans un "cycle" de toute façon, donc les demandes volumineuses finissent toujours par vous coûter plusieurs IOPS.
Il y a un bon article ici d'Amazon eux-mêmes sur les IOPS et les coûts, et les `` économies '' qu'ils répercutent grâce aux optimisations
Caractéristiques d'E/S et surveillance
Pas tout lu mais ça a l'air intéressant, si vous êtes curieux de ce domaine.
D'une manière générale, l'IOPS est plus difficile à obtenir que le débit. Si vous avez beaucoup d'IOPS, vous aurez la plupart du temps un débit suffisant.
Avec les disques durs classiques, le nombre d'axes est votre facteur limitant, car la tête doit être physiquement déplacée sur chaque disque: et c'est terriblement lent. Les SSD ont une bien meilleure capacité IOPS.
Si vous n'avez qu'un seul utilisateur, copiant un gros fichier sur le réseau, vous n'aurez peut-être qu'une douzaine de recherches pour obtenir les données, et le reste ne sera diffusé qu'à partir du disque.
Cependant, si vous utilisez une base de données ou si vous avez beaucoup d'utilisateurs simultanés, vous devrez accéder à différentes parties de votre stockage en même temps, avec la montée en flèche des IOPS.
La simple mise à jour de 10 lignes en parallèle sur une base de données relationnelle peut aboutir à la génération de centaines d'E/S: lecture des index, lecture des données, ajout du fichier journal, mise à jour des index et des données. La plupart des systèmes d'exploitation et des bases de données s'efforcent de limiter le nombre d'E/S en mettant en cache et en retardant/groupant les E/S lorsque cela est possible.
Je répondrai également à ma propre question parce que je pense que la plupart des réponses vont beaucoup hors sujet et la réponse pourrait être beaucoup plus simple:
Si vous ne regardez que le débit de vos périphériques de stockage, vous risquez de manquer ce qui se passe ... S'il y a un faible débit (faible Mo/s), vous pouvez avoir un périphérique lent OR ayant beaucoup de accès aléatoire dans un disque dur ou un autre appareil qui ne gère pas bien l'accès aléatoire.
En examinant les IOPS et en connaissant la taille de bloc de chaque opération d'E/S, vous pouvez savoir combien d'accès le périphérique de stockage est capable de gérer et quel est le débit de ces IOPS (taille de bloc * IOPS).
Donc, en regardant des IOPS élevés, vous pouvez conclure que votre périphérique de stockage gère beaucoup d'accès aléatoire, même si cela vient avec un faible débit .... ou peut-être que vous recherchez des IOPS faibles qui ont le même débit faible, ce qui signifie que votre appareil est juste tourner au ralenti.
Donc, en regardant les IOPS, nous pouvons avoir une idée de ce que signifie réellement le débit, ils se complètent tous les deux.