Umgang mit MySQL Long Running Queries

Lange laufende Abfragen/Anweisungen/Transaktionen sind in einer MySQL-Umgebung manchmal unvermeidlich. In einigen Fällen kann eine lange laufende Abfrage ein Katalysator für ein katastrophales Ereignis sein. Wenn Sie sich um Ihre Datenbank kümmern, müssen Sie regelmäßig die Abfrageleistung optimieren und lang andauernde Abfragen erkennen. Die Dinge werden jedoch schwieriger, wenn mehrere Instanzen in einer Gruppe oder einem Cluster beteiligt sind.

Beim Umgang mit mehreren Knoten müssen wir die sich wiederholenden Aufgaben zur Überprüfung jedes einzelnen Knotens vermeiden. ClusterControl überwacht mehrere Aspekte Ihres Datenbankservers, einschließlich Abfragen. ClusterControl aggregiert alle abfragebezogenen Informationen von allen Knoten in der Gruppe oder im Cluster, um eine zentralisierte Ansicht der Arbeitslast bereitzustellen. Genau das ist eine großartige Möglichkeit, Ihren Cluster mit minimalem Aufwand als Ganzes zu verstehen.

In diesem Blogbeitrag zeigen wir Ihnen, wie Sie mit ClusterControl lange laufende MySQL-Abfragen erkennen.

Warum eine Abfrage länger dauert?

Zunächst müssen wir die Art der Abfrage kennen, ob es sich voraussichtlich um eine lange oder eine kurze Abfrage handelt. Einige Analyse- und Stapeloperationen sollen Abfragen mit langer Laufzeit sein, daher können wir diese vorerst überspringen. Außerdem kann das Ändern der Tabellenstruktur mit dem ALTER-Befehl je nach Tabellengröße eine lang andauernde Operation sein.

Bei einer Transaktion mit kurzer Spanne sollte sie so schnell wie möglich ausgeführt werden, normalerweise innerhalb von Sekundenbruchteilen. Je kürzer desto besser. Dies beinhaltet eine Reihe von Best-Practice-Regeln für Abfragen, die Benutzer befolgen müssen, wie z /Traffic an dedizierte Replikate melden usw.

Es gibt eine Reihe von Dingen, die dazu führen können, dass die Ausführung einer Abfrage länger dauert:

• Ineffiziente Abfrage - Verwenden Sie nicht indizierte Spalten beim Suchen oder Verbinden, daher braucht MySQL länger, um die Bedingung zu erfüllen.
• Tabellensperre - Die Tabelle ist gesperrt, durch globale Sperre oder explizite Tabellensperre, wenn die Abfrage versucht, darauf zuzugreifen.
• Deadlock – Eine Abfrage wartet darauf, auf dieselben Zeilen zuzugreifen, die durch eine andere Abfrage gesperrt sind.
• Datensatz passt nicht in RAM - Wenn Ihre Arbeitssatzdaten in diesen Cache passen, sind SELECT-Abfragen normalerweise relativ schnell.
• Suboptimale Hardwareressourcen – Dies können langsame Festplatten, RAID-Neuaufbau, überlastetes Netzwerk usw. sein.
• Wartungsvorgang - Das Ausführen von mysqldump kann riesige Mengen ansonsten ungenutzter Daten in den Pufferpool bringen, und gleichzeitig werden die (potentiell nützlichen) Daten, die bereits vorhanden sind, entfernt und auf die Festplatte geschrieben.

Die obige Liste betont, dass nicht nur die Abfrage selbst alle möglichen Probleme verursacht. Es gibt viele Gründe, die es erforderlich machen, verschiedene Aspekte eines MySQL-Servers zu betrachten. In einem schlimmeren Szenario kann eine lange laufende Abfrage zu einer vollständigen Dienstunterbrechung wie Serverausfall, Serverabsturz und maximaler Verbindungsauslastung führen. Wenn Sie feststellen, dass die Ausführung einer Abfrage länger als gewöhnlich dauert, untersuchen Sie sie.

Wie überprüfe ich?

PROZESSLISTE

MySQL stellt eine Reihe von integrierten Tools bereit, um lang andauernde Transaktionen zu überprüfen. Zunächst einmal können die Befehle SHOW PROCESSLIST oder SHOW FULL PROCESSLIST die laufenden Abfragen in Echtzeit anzeigen. Hier ist ein Screenshot der ClusterControl Running Queries-Funktion, ähnlich dem Befehl SHOW FULL PROCESSLIST (aber ClusterControl aggregiert den gesamten Prozess in einer Ansicht für alle Knoten im Cluster):

Wie Sie sehen können, können wir die anstößige Abfrage sofort in der Ausgabe sehen. Aber wie oft starren wir auf diese Prozesse? Dies ist nur nützlich, wenn Sie sich der lang andauernden Transaktion bewusst sind. Andernfalls würden Sie es nicht wissen, bis etwas passiert - wie sich die Verbindungen häufen oder der Server langsamer als gewöhnlich wird.

Protokoll für langsame Abfragen

Das Protokoll für langsame Abfragen erfasst langsame Abfragen (SQL-Anweisungen, die länger als long_query_time dauern Sekunden zur Ausführung) oder Abfragen, die keine Indizes für Suchen verwenden (log_queries_not_using_indexes ). Diese Funktion ist standardmäßig nicht aktiviert und um sie zu aktivieren, setzen Sie einfach die folgenden Zeilen und starten Sie den MySQL-Server neu:

[mysqld]
slow_query_log=1
long_query_time=0.1
log_queries_not_using_indexes=1

Das Protokoll für langsame Abfragen kann verwendet werden, um Abfragen zu finden, deren Ausführung lange dauert und die daher Kandidaten für eine Optimierung sind. Das Untersuchen eines langen, langsamen Abfrageprotokolls kann jedoch eine zeitaufwändige Aufgabe sein. Es gibt Tools zum Analysieren von MySQL-Logdateien für langsame Abfragen und zum Zusammenfassen ihrer Inhalte wie mysqldumpslow, pt-query-digest oder ClusterControl Top Queries.

ClusterControl Top Queries fasst die langsame Abfrage mit zwei Methoden zusammen - MySQL Slow Query Log oder Performance Schema:

Sie können leicht eine Zusammenfassung der normalisierten Anweisungsauszüge sehen, sortiert nach einer Reihe von Kriterien:

• Host
• Vorkommen
• Gesamtausführungszeit
• Maximale Ausführungszeit
• Durchschnittliche Ausführungszeit
• Standardabweichungszeit

Wir haben diese Funktion ausführlich in diesem Blog-Beitrag behandelt, How to use the ClusterControl Query Monitor for MySQL, MariaDB and Percona Server.

Leistungsschema

Performance Schema ist ein großartiges Tool, das für die Überwachung von MySQL Server-Interna und Ausführungsdetails auf niedrigerer Ebene verfügbar ist. Die folgenden Tabellen im Leistungsschema können verwendet werden, um langsame Abfragen zu finden:

• events_statements_current
• events_statements_history
• events_statements_history_long
• events_statements_summary_by_digest
• events_statements_summary_by_user_by_event_name
• events_statements_summary_by_host_by_event_name

MySQL 5.7.7 und höher enthält das sys-Schema, eine Reihe von Objekten, die DBAs und Entwicklern helfen, die vom Performance-Schema gesammelten Daten in leichter verständlicher Form zu interpretieren. Sys-Schema-Objekte können für typische Tuning- und Diagnose-Anwendungsfälle verwendet werden.

ClusterControl stellt Advisors zur Verfügung, bei denen es sich um Miniprogramme handelt, die Sie mit ClusterControl DSL (ähnlich wie JavaScript) schreiben können, um die ClusterControl-Überwachungsfunktionen Ihren Anforderungen entsprechend zu erweitern. Basierend auf dem Leistungsschema ist eine Reihe von Skripts enthalten, mit denen Sie die Abfrageleistung überwachen können, z. B. E/A-Wartezeit, Wartezeit für Sperren usw. Zum Beispiel unter Verwalten -> Developer Studio , gehen Sie zu s9s -> mysql -> p_s -> top_tables_by_iowait.js und klicken Sie auf die Schaltfläche "Compile and Run". Sie sollten die Ausgabe auf der Registerkarte Nachrichten für die Top-10-Tabellen sehen, sortiert nach E/A-Wartezeit pro Server:

Es gibt eine Reihe von Skripts, die Sie verwenden können, um Low-Level-Informationen zu verstehen, wo und warum die Langsamkeit auftritt, wie top_tables_by_lockwait.js , top_accessed_db_files.js und so weiter.

ClusterControl - Erkennung und Warnung bei lang andauernden Abfragen

Mit ClusterControl erhalten Sie zusätzliche leistungsstarke Funktionen, die Sie in der Standard-MySQL-Installation nicht finden werden. ClusterControl kann so konfiguriert werden, dass es die laufenden Prozesse proaktiv überwacht und einen Alarm auslöst und eine Benachrichtigung an den Benutzer sendet, wenn der Schwellenwert für lange Abfragen überschritten wird. Dies kann über die Laufzeitkonfiguration unter Einstellungen:

Für pre1.7.1 der Standardwert für query_monitor_alert_long_running_query ist falsch. Wir empfehlen Benutzern, dies zu aktivieren, indem sie es auf 1 (true) setzen. Um es dauerhaft zu machen, fügen Sie die folgende Zeile in /etc/cmon.d/cmon_X.cnf hinzu:

query_monitor_alert_long_running_query=1
query_monitor_long_running_query_ms=30000

Alle Änderungen, die in der Laufzeitkonfiguration vorgenommen werden, werden sofort übernommen und es ist kein Neustart erforderlich. Wenn eine Abfrage den Schwellenwert von 30.000 ms (30 Sekunden) überschreitet, sehen Sie in etwa Folgendes im Abschnitt "Alarme":

Wenn Sie die E-Mail-Empfängereinstellungen als „Zustellen“ für die Schweregradkategorie „DbComponent“ plus „KRITISCH“ konfigurieren (wie im folgenden Screenshot gezeigt):

Sie sollten eine Kopie dieses Alarms in Ihrer E-Mail erhalten. Andernfalls kann es manuell weitergeleitet werden, indem Sie auf die Schaltfläche "E-Mail senden" klicken.

Darüber hinaus können Sie jede Art von Processlist-Ressourcen herausfiltern, die bestimmten Kriterien mit regulären Ausdrücken (Regex) entsprechen. Wenn Sie beispielsweise möchten, dass ClusterControl lang andauernde Abfragen für drei MySQL-Benutzer namens „sbtest“, „myshop“ und „db_user1“ erkennt, sollte Folgendes funktionieren:

Alle Änderungen, die in der Laufzeitkonfiguration vorgenommen werden, werden sofort angewendet und es ist kein Neustart erforderlich.

Zusätzlich listet ClusterControl alle Deadlock-Transaktionen zusammen mit dem InnoDB-Status auf, als sie unter Performance -> Transaction Log stattfanden :

Diese Funktion ist standardmäßig nicht aktiviert, da die Deadlock-Erkennung die CPU-Auslastung auf Datenbankknoten beeinträchtigt. Aktivieren Sie zum Aktivieren einfach das Kontrollkästchen "Transaktionsprotokoll aktivieren" und geben Sie das gewünschte Intervall an. Um es dauerhaft zu machen, fügen Sie eine Variable mit einem Wert in Sekunden in /etc/cmon.d/cmon_X.cnf:

db_deadlock_check_interval=30

Wenn Sie den InnoDB-Status überprüfen möchten, gehen Sie einfach zu Leistung -> InnoDB-Status , und wählen Sie den MySQL-Server aus der Dropdown-Liste aus. Zum Beispiel:

Los geht's - alle erforderlichen Informationen sind mit wenigen Klicks leicht abrufbar.

Zusammenfassung

Lang andauernde Transaktionen können zu Leistungseinbußen, Serverausfällen, ausgelasteten Verbindungen und Deadlocks führen. Mit ClusterControl können Sie lange laufende Abfragen direkt über die Benutzeroberfläche erkennen, ohne jeden einzelnen MySQL-Knoten im Cluster untersuchen zu müssen.