Eine schlechte Abfrageleistung ist das häufigste Problem, mit dem DBAs zu kämpfen haben. Es gibt zahlreiche Möglichkeiten, die Daten zur Abfrageleistung zu sammeln, zu verarbeiten und zu analysieren – wir haben eines der beliebtesten Tools, pt-query-digest, in einigen unserer früheren Blogbeiträge behandelt:
Werden Sie eine MySQL DBA-Blogserie
- Analysieren Ihrer SQL-Workload mit pt-query-digest
- Deep Dive SQL Workload Analysis mit pt-query-digest
Wenn Sie ClusterControl verwenden, ist dies jedoch nicht immer erforderlich. Sie können die in ClusterControl verfügbaren Daten verwenden, um Ihr Problem zu lösen. In diesem Blogbeitrag untersuchen wir, wie ClusterControl Ihnen helfen kann, Probleme im Zusammenhang mit der Abfrageleistung zu lösen.
Es kann vorkommen, dass eine Abfrage nicht zeitnah abgeschlossen werden kann. Die Abfrage kann aufgrund einiger Sperrprobleme hängen bleiben, sie ist möglicherweise nicht optimal oder nicht richtig indiziert oder sie ist zu umfangreich, um sie in angemessener Zeit abzuschließen. Denken Sie daran, dass einige nicht indizierte Joins problemlos Milliarden von Zeilen scannen können, wenn Sie über eine große Produktionsdatenbank verfügen. Was auch immer passiert ist, die Abfrage verwendet wahrscheinlich einige der Ressourcen - sei es CPU oder I/O für eine nicht optimierte Abfrage oder sogar nur Zeilensperren. Diese Ressourcen werden auch für andere Abfragen benötigt und können die Dinge erheblich verlangsamen. Eine sehr einfache, aber wichtige Aufgabe wäre es, die problematische Abfrage zu lokalisieren und zu stoppen.
Dies ist ziemlich einfach über die ClusterControl-Oberfläche möglich. Gehen Sie zur Registerkarte „Abfragemonitor“ -> „Running Queries“ – Sie sollten eine Ausgabe sehen, die der Abbildung unten ähnelt.
Wie Sie sehen können, haben wir einen Haufen Abfragen festgefahren. Normalerweise ist die anstößige Abfrage diejenige, die viel Zeit in Anspruch nimmt, Sie möchten sie vielleicht beenden. Möglicherweise möchten Sie es auch weiter untersuchen, um sicherzustellen, dass Sie das richtige auswählen. In unserem Fall sehen wir deutlich ein SELECT … FOR UPDATE, das ein paar Tabellen verbindet und sich für die letzten 90 Sekunden im Zustand „Daten senden“ befindet, was bedeutet, dass es die Daten verarbeitet.
Eine andere Art von Frage, die ein DBA möglicherweise beantworten muss, lautet:Welche Abfragen benötigen die meiste Zeit zur Ausführung? Dies ist eine häufig gestellte Frage, da solche Abfragen eine „Low Hanging Fruit“ sein können – sie können optimiert werden, und je mehr Ausführungszeit eine bestimmte Abfrage in einem gesamten Abfragemix verantwortet, desto größer ist der Gewinn aus ihrer Optimierung. Es ist eine einfache Gleichung:Wenn eine Abfrage für 50 % der gesamten Ausführungszeit verantwortlich ist, führt eine 10-mal schnellere Ausführung zu einem viel besseren Ergebnis als die Optimierung einer Abfrage, die nur für 1 % der gesamten Ausführungszeit verantwortlich ist.
ClusterControl kann Ihnen bei der Beantwortung solcher Fragen helfen, aber zuerst müssen wir sicherstellen, dass der Query Monitor aktiviert ist. Sie können den Abfragemonitor auf der Seite „Abfragemonitor“ aktivieren. Darüber hinaus können Sie unter Einstellungen die Option „Lange Abfragezeit“ und „Abfragen ohne Indizes protokollieren“ entsprechend Ihrer Auslastung konfigurieren:
Der Abfragemonitor in ClusterControl arbeitet in zwei Modi, je nachdem, ob Sie das Performance-Schema mit den erforderlichen Daten zu den laufenden Abfragen zur Verfügung haben oder nicht. Wenn es verfügbar ist (und dies ist standardmäßig in MySQL 5.6 und höher der Fall), wird das Leistungsschema verwendet, um Abfragedaten zu sammeln, wodurch die Auswirkungen auf das System minimiert werden. Andernfalls wird das langsame Abfrageprotokoll verwendet und alle im obigen Screenshot sichtbaren Einstellungen werden verwendet. Diese werden in der Benutzeroberfläche ziemlich gut erklärt, sodass Sie dies hier nicht tun müssen. Wenn der Abfragemonitor das Leistungsschema verwendet, werden diese Einstellungen nicht verwendet (mit Ausnahme des Ein-/Ausschaltens des Abfragemonitors zum Aktivieren/Deaktivieren der Datenerfassung).
Wenn Sie bestätigt haben, dass der Query Monitor in ClusterControl aktiviert ist, können Sie zu Query Monitor -> Top Queries gehen, wo Ihnen ein Bildschirm ähnlich dem folgenden angezeigt wird:
Was Sie hier sehen können, ist eine Liste der teuersten Abfragen (in Bezug auf die Ausführungszeit), die unseren Cluster getroffen haben. Jeder von ihnen hat einige weitere Details – wie oft er ausgeführt wurde, wie viele Zeilen untersucht oder an den Client gesendet wurden, wie die Ausführungszeit variierte, wie viel Zeit der Cluster für die Ausführung eines bestimmten Abfragetyps aufwendete. Abfragen werden nach Abfragetyp und Schema gruppiert.
Sie werden überrascht sein, dass der Hauptort, an dem die Ausführungszeit verbracht wird, eine „COMMIT“-Abfrage ist. Eigentlich ist dies ziemlich typisch für schnelle OLTP-Abfragen, die auf dem Galera-Cluster ausgeführt werden. Das Festschreiben einer Transaktion ist ein teurer Prozess, da eine Zertifizierung erfolgen muss. Dies führt dazu, dass COMMIT eine der zeitaufwändigsten Abfragen im Abfragemix ist.
Wenn Sie auf eine Abfrage klicken, können Sie die vollständige Abfrage, die maximale Ausführungszeit, die Anzahl der Vorkommen, einige allgemeine Optimierungshinweise und eine EXPLAIN-Ausgabe dafür sehen – ziemlich nützlich, um festzustellen, ob etwas damit nicht stimmt. In unserem Beispiel haben wir ein SELECT … FOR UPDATE mit einer hohen Anzahl von untersuchten Zeilen überprüft. Wie erwartet ist diese Abfrage ein Beispiel für schreckliches SQL – ein JOIN, der keinen Index verwendet. Sie können in der EXPLAIN-Ausgabe sehen, dass kein Index verwendet wird, nicht einmal ein einziger wurde für möglich gehalten. Kein Wunder, dass diese Abfrage die Leistung unseres Clusters ernsthaft beeinträchtigt hat.
Eine andere Möglichkeit, einen Einblick in die Abfrageleistung zu erhalten, besteht darin, sich Query Monitor -> Query Outliers anzusehen. Dies ist im Grunde eine Liste von Abfragen, deren Leistung erheblich von ihrem Durchschnitt abweicht.
Wie Sie im obigen Screenshot sehen können, dauerte die zweite Abfrage 0,01116 Sekunden (die Zeit wird in Millisekunden angezeigt), wobei die durchschnittliche Ausführungszeit für diese Abfrage viel niedriger ist (0,000142 Sekunden). Wir haben auch einige zusätzliche statistische Informationen zur Standardabweichung und zur maximalen Abfrageausführungszeit. Eine solche Liste von Abfragen mag nicht sehr nützlich erscheinen - es ist nicht wirklich wahr. Wenn Sie eine Abfrage in dieser Liste sehen, bedeutet dies, dass etwas anders als gewöhnlich war – die Abfrage wurde nicht rechtzeitig abgeschlossen. Dies kann ein Hinweis auf einige Leistungsprobleme auf Ihrem System und ein Signal dafür sein, dass Sie andere Metriken untersuchen und überprüfen sollten, ob zu diesem Zeitpunkt etwas anderes passiert ist.
Die Leute neigen dazu, sich darauf zu konzentrieren, maximale Leistung zu erzielen, und vergessen, dass ein hoher Durchsatz nicht ausreicht – er muss auch konsistent sein. Benutzer mögen eine stabile Leistung - Sie können möglicherweise mehr Transaktionen pro Sekunde aus Ihrem System herausquetschen, aber wenn dies bedeutet, dass einige Transaktionen für Sekunden ins Stocken geraten, lohnt sich das nicht. Ein Blick auf das Abfragehistogramm in ClusterControl hilft Ihnen, solche Konsistenzprobleme in Ihrem Abfragemix zu identifizieren.
Viel Spaß beim Abfragen-Monitoring!
PS.:Um mit ClusterControl zu beginnen, klicken Sie hier!
