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

Les 2 serveurs sont à peu près les mêmes, la seule différence est le contrôleur RAID et le volume virtuel (les HD sont les mêmes). Sur la production, il y a un contrôleur HW RAID 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 des validations de MySQL, nous avons des attentes élevées:

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 et 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 de raid, comment puis-je en être sûr?

Ma réponse comportait 2 parties: enquête sur le pilote de périphérique de bloc; et l'optimisation mérite d'être examinée avec votre cas d'utilisation. Mais j'ai supprimé la dernière partie car il a été signalé que cela pouvait entraîner 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 ensembles différents de matériel, les performances sont très différentes et vous aimeriez comprendre pourquoi. Je propose donc d'abord un moyen de vous aider à trouver une réponse au «pourquoi».

Pour les performances, je me réfère souvent à la Linux Performance Map fournie par Brendan Gregg sur son blog. On peut voir que pour le bas niveau (le plus proche du matériel) un outil comme blktraceserait parfait.

Ne connaissant pas vraiment cet outil, j'ai cherché et trouvé cet article intéressant concernant blktrace par Marc Brooker. Fondamentalement, il suggère ce qui suit: effectuer une trace d'E / S en utilisant blktrace; en utilisant 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 les entrées D2C. Il vous donnera une idée du temps qu'il faut pour qu'une E / S livrée au pilote de périphérique soit signalée comme terminée par ce pilote.

Exemple de sortie (en dnf upgradecours d'exécution sur une machine virtuelle VirtualBox sur mon ordinateur portable occupé):

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

...
D2C               0.000046515   0.045781696   3.940577359       11713
...

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

Pour plus de façons d'utiliser blktrace pour effectuer cette enquête, lisez l'article de Marc Brooker, très instructif.

Le processus jbd2 est destiné au journalisation ext4. Il est logique que le système de fichiers doive écrire dans le journal pendant les validations mysql, cela ne devrait pas être une source de soucis. 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 une journalisation très conservatrice sur la partition de la base de données pour vous assurer que votre base de données ne soit pas corrompue si quelque chose se produit et que votre serveur redémarre accidentellement. Vous pouvez sélectionner une autre option de montage de journalisation dans l'environnement de test juste pour comparaison.