Wir haben also einen Server, der scheinbar zufällige Spitzen bei der Festplatten-E/A aufweist, die zu zufälligen Zeiten und ohne ersichtlichen Grund auf 99,x % steigen, eine Zeit lang hoch bleiben und dann wieder abfallen. Dies war früher kein Problem, aber in letzter Zeit blieb die Festplatten-E/A für längere Zeiträume bei 99 %, in einigen Fällen bis zu 16 Stunden.
Der Server ist ein dedizierter Server mit 4 CPU-Kernen und 4 GB RAM. Er läuft mit Ubuntu Server 14.04.2, Percona-Server 5.6 und sonst nichts Wichtiges. Er wird auf Ausfallzeiten überwacht und wir haben einen Bildschirm, der permanent CPU/RAM/Disk I/O für die Server anzeigt, mit denen wir arbeiten. Der Server wird außerdem regelmäßig gepatcht und gewartet.
Dieser Server ist der dritte in einer Kette von Replikaten und dient als Failover-Maschine. Der MySQL-Datenfluss ist wie folgt.
Master --> Master/Slave --> Problemserver
Alle 3 Maschinen haben identische Spezifikationen und werden von derselben Firma gehostet. Der Problemserver befindet sich in einem anderen Rechenzentrum als der erste und der zweite.
Das Tool „iotop“ zeigt uns, dass die Festplatten-E/A durch den Prozess „jbd2/sda7-8“ verursacht wird. Soweit wir wissen, kümmert sich dieser um die Dateisystem-Journaling und das Leeren von Daten auf die Festplatte. Unsere „sda7“-Partition ist „/var“ und unsere sda8-Partition ist /home. Es sollte nichts regelmäßig in /home gelesen oder geschrieben werden. Das Stoppen des MySQL-Dienstes führt dazu, dass die Festplatten-E/A sofort wieder auf ein normales Niveau zurückfällt. Wir sind also ziemlich sicher, dass das Problem durch Percona verursacht wird. Dies würde damit übereinstimmen, dass es die Partition /var ist, da sich dort unser MySQL-Datenverzeichnis befindet (/var/lib/mysql).
Wir verwenden NewRelic, um alle unsere Server zu überwachen, und wenn die Festplatten-E/A-Spitzen erreicht werden, können wir nichts erkennen, was die Ursache dafür sein könnte. Die durchschnittliche Auslastung liegt bei ~2. Die CPU-Auslastung schwankt bei ~25 %, was laut NewRelic eher durch „IO Wait“ als durch einen bestimmten Prozess verursacht wird.
Unsere MySQL-Konfigurationsdatei wurde durch eine Kombination des Percona-Konfigurationsassistenten und einiger Einstellungen generiert, die für die App unserer Kunden erforderlich sind, ist aber nichts besonders Ausgefallenes.
MySQL-Konfiguration -http://pastebin.com/5iev4eNa
Wir haben Folgendes versucht, um das Problem zu beheben:
Habe mysqltuner.pl ausgeführt, um zu sehen, ob offensichtlich etwas nicht stimmt. Die Ergebnisse ähneln sehr stark den Ergebnissen desselben Tools auf den beiden anderen Datenbankservern und ändern sich zwischen den Anwendungen nicht sehr.
Habe vmstat, iotop, iostat, pt-diskstats, fatrace, lsof, pt-stalk und wahrscheinlich noch ein paar mehr verwendet, aber es ist mir nichts Auffälliges aufgefallen.
Habe die Variable 'innodb_flush_log_at_trx_commit' optimiert. Habe versucht, sie auf 0, 1 und 2 zu setzen, aber nichts schien irgendeinen Effekt zu haben. Dies hätte die Häufigkeit ändern sollen, mit der MySQL Transaktionen in die Protokolldateien schreibt.
Eine MySQL-Anweisung „Vollständige Prozessliste anzeigen“ ist bei hohem Platten-E/A sehr uninteressant, da sie lediglich die Lesevorgänge des Slaves vom Master anzeigt.
Einige der Ausgaben der Tools sind offensichtlich ziemlich lang, deshalb gebe ich Pastebin-Links an. Da ich es nicht geschafft habe, die Ausgabe von iotop zu kopieren und einzufügen, habe ich stattdessen einen Screenshot bereitgestellt.
iotop
pt-diskstats:http://pastebin.com/ZYdSkCsL
Wenn die Datenträger-E/A hoch ist, zeigt uns „vmstat 2“, dass die Dinge, die geschrieben werden, hauptsächlich auf „bo“ (Buffer Out) zurückzuführen sind, was mit dem Datenträger-Journaling (Leeren von Puffern/RAM auf Datenträger) korreliert.
„lsof -p mysql-pid“ (Liste der offenen Dateien eines Prozesses) zeigt uns, dass die Dateien, in die geschrieben wird, hauptsächlich .MYI- und .MYD-Dateien im Verzeichnis /var/lib/mysql sowie die Dateien master.info, relay-bin und relay-log sind. Auch ohne Angabe des MySQL-Prozesses (also aller Dateien, die auf dem gesamten Server geschrieben werden) ist die Ausgabe sehr ähnlich (hauptsächlich MySQL-Dateien, sonst nicht viel). Dies bestätigt für mich, dass es definitiv durch Percona verursacht wird.
Bei hohem Festplatten-E/A erhöht sich „seconds_behind_master“. Ich bin mir noch nicht sicher, in welcher Reihenfolge dies geschieht. „seconds_behind_master“ springt auch vorübergehend von normalen Werten auf beliebig große Werte und kehrt dann ziemlich sofort zum Normalwert zurück. Einige Leute haben vorgeschlagen, dass dies durch Netzwerkprobleme verursacht werden könnte.
'Slave-Status anzeigen' -http://pastebin.com/Wj0tFina
Der RAID-Controller (3ware 8006) hat keine Caching-Fähigkeiten; jemand hat auch vorgeschlagen, dass eine schlechte Caching-Leistung das Problem verursachen könnte. Der Controller hat die gleiche Firmware, Version, Revision usw. wie Karten auf anderen Servern desselben Kunden (wenn auch Webserver), also bin ich ziemlich sicher, dass er nicht schuld ist. Ich habe auch Überprüfungen des Arrays durchgeführt, die kein Problem ergeben haben. Wir haben auch das RAID-Überprüfungsskript, das uns auf Änderungen aufmerksam gemacht hätte.
Die Netzwerkgeschwindigkeiten sind im Vergleich zu denen auf dem zweiten Datenbankserver schrecklich, daher denke ich, dass dies möglicherweise ein Netzwerkproblem ist. Dies korreliert auch mit Bandbreitenspitzen kurz bevor die Festplatten-E/A hoch wird. Aber selbst wenn das Netzwerk „Spitzen“ aufweist, ist der Datenverkehr nicht sehr hoch, sondern nur relativ hoch im Vergleich zum Durchschnitt.
Netzwerkgeschwindigkeiten (generiert mit iPerf zu einer AWS-Instanz)
Problemserver - 0,0-11,3 Sek. 2,25 MBytes 1,67 Mbits/Sek. Zweiter Server - 0,0-10,0 Sek. 438 MBytes 366 Mbits/Sek.
Abgesehen davon, dass es langsam ist, scheint das Netzwerk in Ordnung zu sein. Kein Paketverlust, aber einige langsame Hops zwischen den Servern
Ich stelle gerne auch die Ausgabe aller relevanten Befehle bereit, kann diesem Beitrag jedoch nur zwei Links hinzufügen, da ich ein neuer Benutzer bin :(
BEARBEITENWir haben uns diesbezüglich an unseren Hosting-Anbieter gewandt und dieser war so freundlich, die Festplatten gegen SSDs gleicher Größe auszutauschen. Wir haben das RAID auf diesen SSDs neu aufgebaut, aber leider besteht das Problem weiterhin.
Antwort1
Welche Version des MySQL-Servers verwenden Sie? Ab 5.5 können Sie das Leistungsschema verwenden, um Echtzeitstatistiken aus der Datenbank abzurufen. Ich würde mit der Abfrage beginnen:
table_io_waits_summary_by_table
table_io_waits_summary_by_table
table_lock_waits_summary_by_table
um zu sehen, was genau passiert.
Eine andere Lösung wäre, die Nutzung des Pufferpools zu überprüfen. Ist es nicht möglich, dass kalte Seiten vorhanden sind, die in den Speicher verschoben werden müssen?
Antwort2
Der beste Weg, es anzugehen, ist, sich anzusehenhttp://www.brendangregg.com/linuxperf.htmlund befolgen Sie Brendans Rat.
Insbesondere möchten Sie sein iOSnoop-Tool, das Ihnen sagt, wer am häufigsten auf den Speicher zugreift. Aber Sie tun sich selbst einen großen Gefallen, wenn Sie es durchlesen, um seine Denkprozesse und Methoden kennenzulernen, da Ihnen das auf lange Sicht sehr zugute kommen wird.