quelle est la relation entre la taille des blocs et les E / S?
J'ai lu récemment sur le disque ce qui m'a conduit à 3 doutes différents. Et je ne suis pas en mesure de les relier entre eux. Trois termes différents qui me confondent sont block size, IO et Performance.
Je lisais sur le superbloc à slashroot quand j'ai rencontré la déclaration
Moins d'IOPS seront effectuées si vous avez une taille de bloc plus grande pour votre système de fichiers.
D'après cela, je comprends que si je veux lire 1024 Ko de données, un disque (disons A) avec une taille de bloc 4KB/4096B prendrait plus IO qu'un disque (Say B) avec une taille de bloc de 64 Ko.
Maintenant, ma question est de savoir combien de plus IO disque aurait-il besoin?.
Dans la mesure où je comprends le nombre de IO demande requise pour lire ces données dépend également de la taille de chaque IO demande.
So who is deciding what is the size of the IO request? Is it equal to the block size?Certaines personnes disent que votre application décide de la taille de la demande IO qui semble assez juste, mais comment le système d'exploitation divise la demande unique en plusieurs entrées-sorties.There must be a limit after which the request splits in more then one IO. How to find that limit ?Is it possible that in both disk (A and B) the data can be read in same number of IO?Does reading each block means a single IO ? If not how many blocks can be maximum read in a single IO?If the data is sequential or random spread, does CPU provides all block address to read once?
Aussi
nombre d'IOPS possibles = 1/(délai de rotation moyen + temps de recherche moyen)
Débit = IOPS * IO taille
Par dessus, l'IOPS pour un disque serait toujours fixe mais IO peut être variable. Donc, pour calculer le débit maximum possible, nous aurions besoin d'une taille maximale IO. Et d'après ce que je comprends, si je veux augmenter le débit d'un disque, je ferais une demande avec le maximum de données que je peux envoyer dans une demande. Cette hypothèse est-elle correcte?
Je m'excuse pour trop de questions, mais je lis à ce sujet depuis un certain temps et je n'ai pas pu obtenir de réponses satisfaisantes. J'ai trouvé des vues différentes sur le même.
Je pense que article Wikipedia l'explique assez bien:
Absence de spécifications simultanées de temps de réponse et de charge de travail, Les IOPS sont essentiellement dénués de sens.
...
Comme pour les benchmarks, les nombres IOPS publiés par les fabricants de périphériques de stockage ne sont pas directement liés aux performances des applications réelles. ...
Passons maintenant à vos questions:
Alors, qui décide quelle est la taille de la demande IO?
C'est une question à la fois facile et difficile à répondre pour un non-programmeur comme moi.
Comme d'habitude, la réponse est insatisfaisante " cela dépend" ...
Les opérations d'E/S en ce qui concerne le stockage sur disque par une application sont généralement des appels système vers le système d'exploitation et leur taille dépend de l'appel système effectué ...
Je connais mieux Linux que les autres systèmes d'exploitation, je vais donc l'utiliser comme référence.
La taille des opérations d'E/S telles que open() , stat() , chmod() et similaire est presque négligeable.
Sur un disque en rotation, les performances de ces appels dépendent principalement de la quantité nécessaire à l'actionneur de disque pour déplacer le bras et lire la tête à la position correcte sur le plateau de disque.
D'autre part, la taille des appels read() et write() est initialement définie par l'application et peut varier entre 0 Et 0x7ffff000 (2 147 479 552) octets dans une seule demande d'E/S ...
Bien sûr, une fois qu'un tel appel système a été effectué par l'application et reçu par le système d'exploitation, l'appel obtient planifié et mis en file d'attente (selon que le drapeau O_DIRECT a été utilisé pour contourner le page cache et tampons et E/S directes a été sélectionné).
L'appel système abstrait devra être mappé vers/depuis les opérations sur le système de fichiers sous-jacent qui est ordonné en discrets blocs (dont la taille est généralement définie lors de la création du système de fichiers) et éventuellement le pilote de disque fonctionne sur secteurs du disque dur de 512 ou 4096 octets ou des pages de mémoire SSD de 2K, 4K, 8K ou 16K.
(Pour les tests de performances, les appels de lecture et d'écriture sont généralement définis sur 512B ou 4KB, ce qui correspond très bien au disque sous-jacent, ce qui se traduit par des performances optimales.)
Il doit y avoir une limite après laquelle la demande se divise en plusieurs E/S. Comment trouver cette limite?
Oui, il y a une limite, sous Linux comme indiqué dans le manuel, un seul appel système read() ou write() renvoie un maximum de 0x7ffff000 (2 147 479 552) octets. Pour lire des fichiers plus volumineux, vous aurez besoin d'appels système supplémentaires.
La lecture de chaque bloc signifie-t-elle un seul IO?
Pour autant que je sache, chaque occurrence d'un appel système est généralement considérée comme un événement IO.
Un seul appel système read() compte comme 1 événement I/0 et ni X ni Y IO, quelle que soit la façon dont cet appel système est traduit/implémenté pour accéder aux blocs X à partir d'un système de fichiers ou lire les secteurs Y à partir d'un disque dur en rotation .
On dirait que vous essayez de décoder cette déclaration:
"Moins d'IOPS seront effectuées si vous avez une taille de bloc plus grande pour votre système de fichiers."
Permettez-moi d'essayer de reformuler cette déclaration pour clarifier le sens de l'auteur original:
"Pour lire un fichier donné avec une taille particulière (disons, 10 Mo), un système de fichiers formaté avec une taille de bloc plus grande probablement devra effectuer un nombre inférieur d'opérations de lecture qu'un système de fichiers formaté avec une taille de bloc plus petite. "
J'espère que ma reformulation a un peu plus de sens que l'original.
Pour analyser correctement cette déclaration et comprendre la raison pour a) l'utilisation du terme "système de fichiers" au lieu de disque et b) ce satané "probablement", vous devrez en apprendre beaucoup plus sur toutes les couches logicielles entre les données sur un disque (ou SSD) et les applications de l'espace utilisateur. Je peux vous donner quelques conseils pour commencer à googler:
Pour faire tourner les disques:
- taille de secteur (disque) vs taille de bloc (système de fichiers)
En savoir plus sur la mise en cache:
Cache de page/tampon dans le noyau du système d'exploitation
Mise en cache des E/S dans les bibliothèques de niveau utilisateur (dont les plus importantes sont libc et libc ++)
Pour les SSD ou autre stockage basé sur flash, il y a quelques complications supplémentaires. Vous devez rechercher comment fonctionne le stockage flash en unités de pages et pourquoi tout stockage basé sur flash nécessite un processus de récupération de place.