Iowait élevé alors que le wMB / s est faible

J'indexais une table MySQL. Cela fait une charge élevée sur cet ordinateur.

Cela semble dû à un haut débit. Mais cela montre également que le wMB / s n'est que de 2,87.

N'est-ce pas même un disque dur SATA commun capable de gérer plus de 2,87 Mo / s? Pourquoi le processus est-il si lent alors?

iostat -x rapports:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.74    0.00    3.48   47.51    0.00   47.26

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00   300.00    0.00  383.00     0.00     2.87    15.35   142.00  374.64   2.61  99.90
sdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
scd0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdc               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
dm-0              0.00     0.00    0.00 2507.00     0.00     9.79     8.00   263.88  110.06   0.40  99.90
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
dm-2              0.00     0.00    0.00    2.00     0.00     0.01     8.00     0.41  196.00 202.50  40.50
dm-3              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00

Vous effectuez de petites écritures aléatoires, ce qui est à peu près la chose la plus lente que vous pouvez faire sur un disque en rotation, donc je dirais que votre débit répond à (mes) attentes.

Votre avgrq-sztaille est de 15,35, ce qui signifie que votre demande moyenne est de 15,35 x la taille de secteur de votre disque SATA (le plus souvent 512 octets, mais peut-être 4096 octets sur un tout nouveau disque SATA), vous écrivez donc 15,35 x 512 octets = 7 859,2 octets (en moyenne) par requête, le nombre de iostatrapports de 383 écritures / seconde vous donne 3 010 073,6 octets (nous multiplions par une moyenne, c'est de là que viennent les 0,6 octets). Et 3 010 073,6 octets / seconde est de 2,87 Mo / s.

Le nombre d'écritures que vous pouvez effectuer par seconde dépendra de la quantité de disque nécessaire pour déplacer les têtes, mais grosso modo, vous approchez du nombre maximal d'écritures que votre appareil peut effectuer en une seconde.

Des vitesses d'écriture plus élevées sur les disques en rotation se produisent lorsque vous combinez un petit nombre d'écritures par seconde avec une grande avgrq-sz.

S'il s'agit d'un problème de performance critique pour vous, je vous suggère d'étudier les différentes options SSD qui donneront généralement de bien meilleures performances sur une charge de travail comme celle-ci.

Vous devez exécuter iostatplusieurs fois tout en surveillant cela pour créer une image fidèle de ce qui se passe. Cela, ou utilisez un outil comme Cacti pour garder ces statistiques pour vous au fil du temps afin que vous puissiez consulter le graphique historique.

Ce qui se produit le plus probablement, c'est que le disque effectue également beaucoup de lectures, en raison de l'analyse de la table de base de données, et l' iostatexécution que vous avez publiée s'est juste produite à un moment où le SGBD écrivait plutôt qu'il ne lisait. L'écriture entrelacée avec la lecture est vraiment lente sur un disque dur car elle implique la recherche, ce qui est la chose la plus lente qu'un disque dur fait. Si vous écoutez le disque dur, vous pouvez probablement l'entendre cliqueter follement car il alterne rapidement entre l'écriture et la lecture sur différentes parties du disque dur.

Pour que ce processus s'exécute au taux de MByte / s à deux chiffres que vous attendez, vous devez diviser le processus en deux, construire l'index dans la RAM pendant l'analyse de la table, puis écrire l'index complet. MySQL est un logiciel hautement optimisé, donc s'il pouvait le faire, je m'attends à ce qu'il le fasse, et comme il ne l'est pas, il ne le peut pas. C'est-à-dire qu'il n'a probablement pas assez de RAM pour cela. Cela signifie que vous n'avez pas assez de RAM physique dans la machine pour que la partie de MySQL contienne l'index complet, ou que vous ne lui avez pas donné une partie suffisamment élevée de la RAM du système dans le fichier de configuration MySQL. Cependant, l'optimisation de MySQL est un sujet pour un autre forum.