Je vais supposer pour le moment que vous essayez vraiment de comprendre en partie ce qui détermine les débits de données dans le monde réel, et pas seulement en théorie. En général, à moins que vous n'écriviez des pilotes de périphériques pour le système d'exploitation, comme le faisait ma société, ou que vous écriviez le moteur de base de données lui-même, tous ces détails sont un peu banals aujourd'hui. Ces détails réels sont pour la plupart masqués, filtrés, compensés et cachés par de nombreux facteurs liés au matériel et au système d'exploitation, de sorte que vous ne pouvez généralement pas observer directement ce qui se passe.
Il est néanmoins important de comprendre ce qui cause ou non des problèmes de performance.
Le "taux de lecture de données" moyen pour les bases de données dépendra principalement de la taille de l'entrée-sortie que vous déplacez à un moment donné, et si elle est contiguë ou non. Il dépend également du disque lui-même, en indiquant ses véritables paramètres matériels, qui ne sont souvent que simulés. (Par exemple, y a-t-il vraiment 600 secteurs par piste ? Comme la piste extérieure d'un disque est beaucoup plus grande, n'importe quel disque des 30 dernières années aura beaucoup plus de secteurs sur la piste extérieure que sur la piste intérieure). Voici quelques exemples de performances si ces paramètres étaient les vrais :
Lecture de la base de données : Signifie généralement que les numéros de secteur seront lus de manière aléatoire sur tout le disque, (vraisemblablement 1024 octets de 2 secteurs 512 consécutifs), et qu'aucun des secteurs ne se trouve en mémoire ou dans un autre cache : Dans ce cas, votre débit moyen sera de :
10 MS = Repositionnement de la tête de recherche : (Notez que cela signifie que vous ne pouvez faire que 100 recherches en 1 sec, et donc 100 KB / Sec va être le plus RAPIDE que vous pouvez jamais lire 1024 aléatoirement).
1 ? MS = Command overhead = inconnu : C'était autrefois important, jusqu'à 8 MS. Aujourd'hui, il est probable qu'il dépende davantage de votre système d'exploitation, qui traite vos demandes efficacement. Donc, si votre système échange également de nombreux Mo sur le disque, votre système subira un ralentissement significatif. Les IO vers et depuis les disques aujourd'hui, sont probablement inférieures à un MS. Ceci pourrait être testé facilement avec un SSD pour simuler le bus d'un disque dur rotatif et la surcharge du firmware. Le temps nécessaire pour changer de tête de lecture, en supposant que l'on se trouve déjà sur la bonne piste ou le bon cylindre, est généralement inclus. Cela inclut également le retour des données déplacées vers le système d'exploitation. Surveillez que le temps total d'interruption du CPU reste < 1%, ce qui peut indiquer un problème matériel du disque. Une hypothèse ? < 1 MS, ce qui peut être significatif.
3.3 MS = Tourner jusqu'à ce que le secteur soit sous les têtes : 9000 RPM / 60 sec = 6.67 MS. La probabilité d'être le plus proche ou le plus éloigné est de 50%, donc c'est un délai de 3,33 MS pour chaque IO. Note : Cela signifie qu'une lecture aléatoire si la tête est déjà positionnée sur la bonne piste sera toujours de 3.33 MS, et signifie que votre taux de données maximum ne pourra jamais dépasser 300 KB / Sec. à 1k IO.
0,022 MS = Temps de lecture de la tête : 6,67 MS / 600 secteurs * 2 = 1024 lectures ==> 0,022 MS. Cela signifie que le débit de données maximal de ce disque est de 1 / 0,022 MS = 45 000 * 1024 = 46 Mo / sec. Pour les lectures / requêtes de la base de données, c'est complètement insignifiant, alors que si l'on déplace toute la base de données, ce serait le facteur le plus significatif.
Donc, dans ce cas, votre taux de "lecture de la base de données" sera de ~14.355 MS = 70 KB / sec. Notez que si l'E/S était de 512, (en ignorant le .022 MS), le taux est de moitié. En utilisant 2 048, le taux est doublé. Le paramètre le plus significatif est donc la taille des secteurs contigus, jusqu'à ce que vous arriviez à une lecture de piste complète (en supposant que tous les secteurs du disque sont contigus).