Lösen Sie das Problem des MySQL Threads_running-Surge und der langsamen Abfrage

Hintergrund

Das Jahr vor dem neuen Jahr sollte eine Zeit sein, um die Arbeit des Jahres zu überprüfen und abzuschließen, aber alle möglichen Werbeaktionen und Aktivitäten warten auf das Frühlingsfest, so dass viele Probleme aufgetreten sind. Wenn ich auf die Probleme zurückblicke, die in letzter Zeit aufgetreten sind, stelle ich fest, dass sich einige davon ähneln. Es ist ein guter Zeitpunkt, sie als Fall für den Abschluss vor dem neuen Jahr zu organisieren. Dies äußert sich darin, dass die Datenbank angehalten wird und nicht mehr reagiert. Dies geschieht, wenn ein hoher Geschäftsdruck herrscht oder wenn das Geschäft normal läuft, aber plötzlich Probleme auftreten.

Problembeschreibung

Da die Tencent Cloud Database MySQL selbst über Fehlererkennungs- und Hochverfügbarkeitsmechanismen verfügt, vergingen beim Auftreten dieser Probleme zwar mehrere Minuten zwischen der Meldung des Problems durch den Benutzer und dem eigentlichen Eingriff zur Fehlerbehebung, der Hochverfügbarkeitsschalter wurde jedoch nicht ausgelöst. Dies deutet darauf hin, dass das Problem möglicherweise nicht auf einen Fehler der Datenbank selbst zurückzuführen ist und auch kein externer Grund für die Nichtverfügbarkeit der Datenbank vorliegt.

Als ich damals den Status der Datenbank überprüfte, fand ich einen sehr ungewöhnlichen Indikator:

Etwa zum Zeitpunkt des Problems begannen die Gesamtzahl der Verbindungen und die Anzahl der laufenden Threads innerhalb kurzer Zeit in die Höhe zu schnellen, und fast eine halbe Minute lang konnte nicht einmal das Überwachungs-Plugin Daten erfassen. Im gleichen Zeitraum stiegen auch die CPU-Auslastung (erreichte 100 %) und die Anzahl langsamer Abfragen sprunghaft an. Grundsätzlich lässt sich bestätigen, dass CPU-Auslastung, langsame Abfragen und Anzahl der Verbindungen zusammenhängen. Anhand dieser drei Indikatoren können wir die Ursache dieses Problems analysieren.

Ursachenanalyse

In 99 % der Fälle, in denen die Anzahl langsamer Abfragen rapide ansteigt, liegt das Problem an langsamen Abfragen. Aus einer Fallanalyse kann man jedoch nicht voreilig Schlussfolgerungen ziehen. Da wir nun wieder beim Thema sind und das Ziel auf drei Indikatoren eingegrenzt wurde, wollen wir die Bedeutung dieser drei Indikatoren getrennt betrachten und sehen, welche Probleme die Anomalien dieser Indikatoren verursachen werden.

CPU

Eine hohe CPU-Auslastung zeigt an, dass die Rechenleistung von MySQL voll ausgelastet ist. Nur Benutzer-Threads und MySQLs eigene System-Threads können die Rechenressourcen von MySQL belegen. Dieses Problem hat offensichtlich nichts mit MySQL-System-Threads zu tun. Es zeigt an, dass Benutzer-Threads eine große Menge an CPU-Rechenressourcen belegen und die Auslastungsrate 100 % erreicht, was darauf hinweist, dass der Wettbewerb um diese Ressource sehr stark ist. Dies kann dazu führen, dass die ursprünglich hocheffiziente Abfrage aufgrund des Mangels an CPU-Ressourcen sehr langsam wird und die Abfrage von einer hocheffizienten Abfrage in eine ineffiziente und langsame Abfrage umgewandelt wird, was zum Phänomen des Pseudotodes oder des Hängenbleibens der Datenbank führt.

Langsame Abfrage

Langsame Abfragen sind ein häufiges Problem. Aufgrund der geringen Abfrageeffizienz werden übermäßig viele CPU-, IO-, Speicher- und andere Ressourcen beansprucht, was sich auf andere normale Abfragen auswirkt. Aus den Überwachungsindikatoren können CPU-Auslastung, IO-Auslastung und Speicherauslastung in unterschiedlichem Ausmaß ansteigen. In schweren Fällen steigen diese Indikatoren ebenfalls stark an, was zu einer langsamen Reaktion der gesamten Datenbank führt.

Anzahl der Verbindungen

Die Anzahl der Verbindungen ist normalerweise ein Indikator für einen „tatsächlichen Fehler“. Wenn beispielsweise die Anzahl der Verbindungen die Obergrenze von max_connections erreicht, kann die gesamte Datenbank keine neuen Verbindungen erstellen. Die Programmseite meldet direkt einen Fehler, anstatt nicht zu reagieren. Informationen zum Thread_running-Indikator finden Sie in der Beschreibung im offiziellen Dokument:

Die Anzahl der Threads, die nicht schlafen.

Einfach ausgedrückt bedeutet ein Anstieg dieser Metrik, dass zu diesem Zeitpunkt eine große Anzahl aktiver Benutzer mit der MySQL-Instanz verbunden ist. Und dem Überwachungsdiagramm dieses Falls zufolge gibt es einen steigenden Trend, was darauf schließen lässt, dass in einem kurzen Zeitraum eine große Anzahl aktiver Verbindungen aufgetreten ist.

analysieren

Nach einer einfachen Analyse dieser drei Indikatoren können wir feststellen, dass sie sich gegenseitig beeinflussen:

1. Eine langsame Abfrageakkumulation kann zu einer hohen CPU-Auslastung führen.
2. Eine zu hohe CPU-Auslastung führt zu einer geringeren Gesamtabfrageeffizienz, was wiederum dazu führt, dass einige effiziente Abfragen zu langsamen Abfragen werden.
3. Die Ausführungseffizienz langsamer Abfragen ist zu gering und sie bleiben lange aktiv, sodass der Threads_running-Indikator definitiv ansteigt.
4. Wenn plötzlich übermäßige Parallelität auftritt, führt eine große Anzahl aktiver Abfragen dazu, dass der Threads_running-Indikator in die Höhe schießt. Gleichzeitig kann dieser spitzenartige Peak die CPU leicht füllen.
   

Es scheint, dass die Gründe für den Anstieg dieser drei Indikatoren in sich schlüssig sind und dass sich die Ursache des Problems allein durch die Betrachtung dieser drei Indikatoren nicht wirklich ermitteln lässt. Überlegen Sie also genau, warum die Gründe für den Anstieg dieser Indikatoren in sich schlüssig sind. Sie werden feststellen, dass es ein Kernphänomen oder eine Gemeinsamkeit gibt: Abfragen müssen akkumuliert werden können. Wenn:

1. Die angesammelten Abfragen sind von vornherein nicht effizient, die Ursache dieses Problems sind also grundsätzlich langsame Abfragen.
2. Die akkumulierten Abfragen sind sehr effizient. Die Ursache dieses Problems kann also eine übermäßige momentane Parallelität oder andere Gründe sein, die zu einem Anstieg der CPU-Auslastung führen, was wiederum diese hocheffizienten Abfragen beeinträchtigt.
   

Daher können Sie das Problem direkter identifizieren, indem Sie die akkumulierten Abfragen überprüfen. Im in der obigen Abbildung gezeigten Fall verwenden die akkumulierten Abfragen eine große Anzahl von Group-by- und Order-by-Befehlen und die Abfrageeffizienz ist relativ gering, sodass die Grundursache immer noch eine langsame Abfrage ist.

Expandieren

Wie eingangs erwähnt, gab es in letzter Zeit mehrere Probleme mit ähnlichen Ursachen. Neben diesem Spannungsstoß gibt es auch die unten dargestellten Phänomene.

threads_running bleibt auf einem relativ stabilen Wert. Unter Bezugnahme auf die Analyse im vorherigen Artikel kann festgestellt werden, dass dieses Phänomen bedeutet, dass in normalen Zeiten etwa 10 Abfragen über einen langen Zeitraum aktiv sind. Ein Fehlerszenario kann vorhergesagt werden: Das Geschäftsvolumen nimmt weiter zu und die Anzahl der aktiven Abfragen nimmt zu. Wenn effiziente Abfragen beeinträchtigt werden und die Effizienz bis zu einem gewissen Grad reduziert wird, initiiert das Front-End-Programm/der Benutzer aufgrund eines Timeouts oder einer langsamen Reaktion einen erneuten Versuch. Aufgrund der Verringerung der Abfrageeffizienz wird der erneute Versuch dann wiederholt ausgelöst, was einen Lawineneffekt auslöst und die Datenbank langsam nach unten zieht.

Glücklicherweise gab es unter den zahlreichen Fällen ähnlicher Phänomene nur einen, der ein Problem aufwies. Dies entsprach dem vorhergesagten Szenario, und die anderen wurden rechtzeitig optimiert.

Um zusammenzufassen

Obwohl es sich immer noch um ein Problem langsamer Abfragen handelt, zeigt dieser Fall die Nützlichkeit eines anderen MySQL-Indikators, threads_running: Er überwacht aktive Verbindungen, erkennt im Voraus einige Abfragen mit hoher Parallelität und abnormale Abfragen und verhindert, dass die Datenbank Abfragen ansammelt und einen Pseudotod verursacht.

Oben finden Sie ausführliche Informationen zur Lösung des Problems „MySQL Threads_running surge and slow query“. Weitere Informationen zu „MySQL Threads_running surge and slow query“ finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!