MySQL Server IO 100 % Analyse- und Optimierungslösung

Vorwort

Während des Stresstests besteht das unmittelbarste Leistungsproblem aufgrund von Engpässen bei der Ressourcennutzung darin, dass die Reaktionszeit bei Geschäftstransaktionen zu lang ist und der TPS allmählich abnimmt usw. Bei der Problemortanalyse hat die Überwachung der Serverressourcenauslastung (z. B. mithilfe von TOP oder nmon zum Überprüfen der CPU- und Speicherauslastung) normalerweise höchste Priorität. Anschließend werden E/A-Probleme (z. B. Netzwerk-E/A- und Festplatten-E/A-Probleme) behoben. Wenn es sich um ein Festplatten-E/A-Problem handelt, liegt das allgemeine Problem an einem SQL-Syntaxproblem, einem MySQL-Parameterkonfigurationsproblem oder einem Hardware-Engpass des Servers selbst, der zu einem Problem mit der IOPS-Durchsatzrate führt.

In diesem Artikel werden hauptsächlich der Analyse- und Optimierungsplan für MySQL Server IO 100 % vorgestellt. Werfen wir einen Blick auf die detaillierte Einführung.

【Frage】

Es gibt eine MySQL 5.6.21-Datenbankinstanz, die hauptsächlich schreibbasiert ist, und der IO %util liegt bei nahezu 100 %

Hohe Schreib-IOPS

【Analyseprozess】

1. Mit dem iotop-Tool können Sie den MySQL-Thread mit dem höchsten aktuellen IO-Verbrauch sehen

2. Überprüfen Sie den Stapel von Thread 49342. Sie können sehen, dass das Redo-Protokoll aktualisiert wird, entsprechend Datei 9.

3. Datei Nr. 9 entspricht der ersten Datei des Redo-Logs

Warum aktualisiert der MySQL-Prozess die Redo-Logdatei häufig? Wir müssen dies in Kombination mit der Redo-Log-Flushing-Strategie analysieren. Der Schlüssel ist der Parameter innodb_flush_log_at_trx_commit.

Der Standardwert ist 1, was der sicherste Wert ist. Allerdings kann er bei hohem Schreibdruck auch erhebliche Auswirkungen auf die Leistung haben. Jedes Mal, wenn eine Transaktion festgeschrieben wird, schreibt MySQL die Daten im Protokollpuffer in die Protokolldatei und überträgt sie auf die Festplatte.

In Anbetracht des Schreibszenarios dieses Clusters handelt es sich bei den meisten Schreibvorgängen um kleine Transaktionen, und jedes Transaktionscommit löst eine Datenträgerbereinigung aus. In diesem Szenario ist der Optimierungseffekt einer Erhöhung von innodb_log_buffer_size und innodb_log_file_size nicht offensichtlich.

【Optimierungsplan】

1. Auf Anwendungsebene kann bei Systemen mit hohem Schreibdruck eine einzelne Insert-Anweisung in eine kleine Gruppe von Insert-Anweisungen optimiert werden. Dadurch wird die Anzahl der Transaktions-Commits und Redo-Log-Flushes reduziert und theoretisch die Leistung verbessert.

2. Auf MySQL-Ebene kann bei Systemen vom Typ „Protokoll“ der Parameter innodb_flush_log_at_trx_commit auf 2 eingestellt werden, wenn im Falle von Ausfallzeiten ein geringer Datenverlust zulässig ist.

Wenn der Wert auf 2 gesetzt ist, werden nur Schreibvorgänge ausgeführt, wenn die Transaktion festgeschrieben ist, und es wird garantiert nur in den Systemseitencache geschrieben. Daher gehen Transaktionen nicht verloren, wenn die Instanz abstürzt, aber Transaktionen können verloren gehen, wenn das System abstürzt.

Beim Test auf diesem Server sanken die IO-Anforderungen von 200 M/S auf etwa 10 M/S, wenn der Parameter auf 2 eingestellt wurde, und der Druck verringerte sich um mehr als das Zehnfache.

3. Ersetzen Sie auf Systemebene die Festplatte durch eine leistungsstärkere

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Wenn Sie Fragen haben, können Sie eine Nachricht hinterlassen. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.