Ich habe eine MySQL-Instanz auf zwei dedizierten Servern. Einer für die Produktion, der andere für die Testplattform.

Die 2 Server sind ziemlich gleich, der einzige Unterschied ist der RAID-Controller und das virtuelle Volume (HD sind gleich). In der Produktion gibt es einen dedizierten HW-RAID-Controller und ein RAID 10-Volume. Auf der anderen Seite scheint der RAID-Controller Software zu sein (Lenovo ThinkServer RAID 110i) und das Volume ist RAID 5.

Wir haben festgestellt, dass wir bei MySQL-Commits einen hohen iowait haben:

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 und dm-14-8 beziehen sich auf Datenbankpartitionen.

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

Ich vermute den Raid Controller, wie kann ich sicher sein?

Meine Antwort bestand aus zwei Teilen: Untersuchung des Blockgerätetreibers; und Optimierung, die es wert ist, mit Ihrem Anwendungsfall betrachtet zu werden. Aber ich habe den letzten Teil entfernt, da berichtet wurde, dass dies zu Datenverlust führen kann. Zeige Kommentare.

Untersuchung von Hardware

Ich habe verstanden, dass für dieselbe Anwendung, aber auf 2 verschiedenen Hardwaresätzen, die Leistung sehr unterschiedlich ist und Sie möchten verstehen, warum. Deshalb schlage ich zunächst ein Mittel vor, um Ihnen zu helfen, eine Antwort auf das "Warum" zu finden.

Zur Leistung verweise ich häufig auf die Linux Performance Map von Brendan Gregg in seinem Blog. Man kann sehen, dass für das niedrige Niveau (am nächsten an der Hardware) ein Werkzeug wie blktraceperfekt wäre.

Da ich dieses Tool nicht wirklich kenne , habe ich mich umgesehen und diesen interessanten Artikel über blktrace von Marc Brooker gefunden. Grundsätzlich wird Folgendes vorgeschlagen: Durchführen einer E / A-Ablaufverfolgung mit blktrace; Verwenden des btt- Tools zum Extrahieren von Informationen aus dieser Ablaufverfolgung. Das wäre ungefähr so ​​(für eine 30-Sekunden-Spur):

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

Die Ausgabe kann ziemlich lang sein, aber suchen Sie nach D2C-Einträgen. Sie erhalten eine Vorstellung davon, wie lange es dauert, bis eine an den Gerätetreiber gelieferte E / A als von diesem Treiber abgeschlossen gemeldet wird.

Beispielausgabe ( dnf upgradeläuft auf einer VirtualBox-VM auf meinem ausgelasteten Laptop):

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

...
D2C               0.000046515   0.045781696   3.940577359       11713
...

Es zeigt einen enttäuschenden Durchschnitt von 45 ms pro E / A mit bis zu 3,94 s für den schlimmsten Fall !!

Weitere Möglichkeiten zur Verwendung von blktrace zur Durchführung dieser Untersuchung finden Sie in dem Artikel von Marc Brooker, der sehr lehrreich ist.

Der jbd2-Prozess ist für das ext4-Journaling vorgesehen. Es ist logisch, dass das Dateisystem während MySQL-Commits in ein Journal schreiben muss. Dies sollte kein Grund zur Sorge sein. Die durch jbd verursachte Last wird von Ihren Mount-Parametern für dm-10-8- und dm-14-8-Partitionen beeinflusst. Es ist wahrscheinlich wünschenswert, ein sehr konservatives Journaling auf der Datenbankpartition zu haben, um sicherzustellen, dass Ihre Datenbank nicht beschädigt wird, wenn etwas passiert und Ihr Server versehentlich neu gestartet wird. Sie können in der Testumgebung nur zum Vergleich andere Optionen für die Journalmontage auswählen.