web-dev-qa-db-fra.com

High IO attendre - Comment déterminer la cause première?

J'ai une instance MySQL sur deux serveurs dédiés. Un pour la production, l'autre pour la plate-forme de test.

Les 2 serveurs sont assez identiques, la seule différence est le contrôleur RAID et le volume virtuel (HD sont les mêmes). Sur la production, il existe un contrôleur RAID HW dédié et un volume RAID 10. De l'autre, le contrôleur RAID semble être un logiciel (Lenovo Thinkserver RAID 110i) et le volume est RAID 5.

Nous avons remarqué que lors de MySQL Engagements, nous avons Haute Ioeil:

while true; do date; ps auxf | awk '{if($8=="D") print $0;}'; sleep 1; done
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:37 CEST 2015
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:38 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:39 CEST 2015
Thu Jun 18 13:49:40 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root      1478  0.0  0.0      0     0 ?        D    Jun04   0:03  \_ [jbd2/dm-7-8]
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]

dM-10-8 & DM-14-8 sont liés aux partitions de base de données.

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  3 240904 809656 572624 7114416    0    0    59  1681 2002 5141  3  1 67 30  0
 0  4 240880 809656 572632 7114604    0    0   139  2069 2090 4985  3  1 67 29  0
 1  2 240880 809284 572636 7114676    0    0    27  2159 2253 4247  2  1 72 25  0
 5  2 240880 809408 572656 7114820    0    0    27  2404 2254 5350  3  1 69 27  0

Je soupçonne le contrôleur RAID, comment puis-je être sûr?

linuxmysqlraidiosoftware-raid
10
Bob Sauvage

Ma réponse avait 2 parties: enquête sur le pilote de périphérique de bloc; et l'optimisation qui mérite d'être examinée avec votre cas d'utilisation. Mais j'ai enlevé la dernière partie car il a été signalé qu'il peut conduire à une perte de données. Voir les commentaires.

Enquête sur le matériel

J'ai compris que pour la même application, mais sur 2 différents ensembles de matériel, la performance est très différente et que vous voudriez comprendre pourquoi. Par conséquent, je propose d'abord un moyen de vous aider à trouver une réponse pour le "pourquoi".

Pour la performance, je vous réfère souvent à la carte de performance Linux fournissant par Brendan Gregg sur son blog. On peut voir que pour le niveau bas (le plus proche du matériel), un outil comme blktrace serait parfait.

Je ne connais pas vraiment cet outil, je recherche autour de là et trouvé cela article intéressant concernant BlkTrace de Marc Brooker. Fondamentalement, il suggère ce qui suit: Effectuer une trace d'E/S à l'aide de blktrace; Utilisation de l'outil BTT pour extraire des informations de cette trace. Ce serait quelque chose comme ça (pour une trace de 30 s):

# blktrace -w 30 -d /dev/dm-10-8 -o dm-10-8
# blkparse -d blkmerged.out dm-10-8*
# btt -i blkmerged.out | less

La sortie peut être assez longue, mais recherchez des entrées D2C. Cela vous donnera une idée du temps qu'il faut pour un I/S livré au pilote de périphérique à signaler comme terminé par ce pilote.

Exemple de sortie (dnf upgrade Courir sur une VirtualBox VM sur mon ordinateur portable occupé):

            ALL           MIN           AVG           MAX           N
--------------- ------------- ------------- ------------- -----------

...
D2C               0.000046515   0.045781696   3.940577359       11713
...

Il montre une moyenne décevante de 45 ms par I/S avec jusqu'à 3,94 s pour le pire des cas !!

Pour plus de moyens d'utiliser BlkTrace pour effectuer cette enquête, lisez l'article de Marc Brooker, très instructif.

7
Huygens

le processus JBD2 est destiné à EXT4 JOURNALLING. Il est logique que le système de fichiers a besoin d'écrire dans le journal pendant les engagements mysql, cela ne devrait pas être une raison pour les inquiétudes. La quantité de charge causée par JBD est influencée par vos paramètres de montage pour les partitions DM-10-8 et DM-14-8. Il est probablement souhaitable d'avoir très Conservatioove Journalisant à la partition de base de données pour que votre base de données ne soit pas corrompue si quelque chose se passe et que votre serveur redémarre accidentellement. Vous pouvez sélectionner une autre option de montage de Journalisation dans l'environnement de test juste à titre de comparaison.

1
ludvik02