Die unangemessenen MaxIdleConns von MySQL führen zu kurzen Verbindungen

1 Hintergrund

Vor kurzem sind im Online-Geschäft von Shimo Document einige Leistungsprobleme aufgetreten. Aufgrund plötzlicher Verkehrsprobleme ist die Leistung eines Geschäfts stark gesunken. Dieser Dienst ist von der Datenbank abhängig und ruft die Daten stapelweise aus der Datenbank ab. Nach einer Reihe von Fehlerbehebungen stellten wir fest, dass die Anzahl der Verbindungen vom Dienst zur Datenbank häufig MaxIdleConns überschritt. Wir vermuteten, dass das Leistungsproblem durch die Datenbankkonfiguration verursacht wurde, analysierten daher den Datenbankcode und führten entsprechende Experimente durch.

2 Konfigurationsinterpretation

maxIdleCount int // Null bedeutet defaultMaxIdleConns; negativ bedeutet 0
maxOpen int // <= 0 bedeutet unbegrenzt
maxLifetime time.Duration // Maximale Zeitspanne, für die eine Verbindung wiederverwendet werden kann
maxIdleTime time.Duration // Maximale Zeitspanne, die eine Verbindung im Leerlauf sein darf, bevor sie geschlossen wird

Sie können sehen, dass die oben genannten vier Konfigurationen die wichtigsten Konfigurationen unseres Go MySQL-Clients sind.

maxIdleCount Die maximale Anzahl inaktiver Verbindungen. Standardmäßig ist sie nicht konfiguriert und beträgt maximal 2 inaktive Verbindungen.

maxOpen Die maximale Anzahl von Verbindungen. Standardmäßig ist es nicht konfiguriert, was bedeutet, dass die maximale Anzahl von Verbindungen nicht begrenzt ist.

maxLifetime Maximale Verbindungslebensdauer

maxIdleTime Maximale Lebensdauer inaktiver Verbindungen

3 Quellcode-Analyse

In unserem Szenario ist die Anzahl der vom Client zu MySQL hergestellten Verbindungen häufig größer als die maximale Anzahl inaktiver Verbindungen. Welche Probleme entstehen dadurch? Schauen wir uns den Quellcode in der folgenden Abbildung an.

Wir können sehen, dass, wenn die maximale Anzahl der inaktiven Verbindungen kleiner ist als die Anzahl der zwischen dem Client und der Datenbank hergestellten Verbindungen, „false“ zurückgegeben und der Zähler für die maximale Anzahl von Verbindungsschließungen um 1 erhöht wird.

Dann können wir im Bild oben sehen, dass die Verbindung geschlossen ist (der MySQL-Quellcode lässt vor dem Schließen keine Pufferzeit). Dieser Vorgang des Go MySQL-Clients führt dazu, dass bei einem Verkehrsanstieg das Anforderungsvolumen zu groß ist und die Belastung der maximalen Anzahl inaktiver Verbindungen überschreitet. In diesem Fall werden neue Verbindungen, die in den Verbindungspool aufgenommen werden, rücksichtslos geschlossen und werden zu Kurzverbindungen, was zu einer weiteren Verschlechterung Ihrer Serviceleistung führt.

4 Experimente

4.1 Simulieren Sie die Situation, in der die Anzahl der gleichzeitigen Online-Anrufe größer ist als MaxIdConns

Testcode: Um die obige Logik zu testen, wird das folgende Szenario angenommen. Die maximale Anzahl von Verbindungen ist auf 100 eingestellt, die maximale Anzahl von inaktiven Verbindungen beträgt 1 und die Anzahl gleichzeitiger Goroutinen zum Anfordern der Datenbank beträgt 10. Anhand der Statistik von maxIdleClosed in den MySQL-Statistiken können wir die folgende Abbildung erkennen: Unsere Verbindungen werden ständig geschlossen.

4.2 Simulation einer Situation, in der die Anzahl gleichzeitiger Onlineverbindungen kleiner ist als MaxIdConns

Der Testcode geht von folgendem Szenario aus: Die maximale Anzahl von Verbindungen ist auf 100 eingestellt, die maximale Anzahl von Leerlaufverbindungen ist auf 20 eingestellt und die Anzahl gleichzeitiger Goroutinen zum Anfordern der Datenbank ist auf 10 eingestellt. Wie in der folgenden Abbildung zu sehen ist, gibt es keine MaxIdleClosed-Schließstatistik.

4.3 Erfassen Sie Pakete, um zu überprüfen, ob die Anzahl der Online-Parallelitäten größer als MaxIdConns ist

Testen Sie den Code. Um sicherzustellen, dass Sie den Code nicht missverstanden haben, ist es am sichersten, ein Paket zu erfassen. Wir setzen ein select{} in die Hauptfunktion. Nachdem das Programm die MySQL-Anweisung ausgeführt hat, überprüfen wir den TCP-Status und die Paketerfassungsdaten.

Es kann festgestellt werden, dass die TCP-Statusstatistiken mit den MySQL-Clientstatistiken übereinstimmen und das Fin-Paket vorhanden ist.

5 Fazit

Bei einem Verkehrsanstieg ist das Anforderungsvolumen zu groß und überschreitet die Belastung der maximalen Anzahl inaktiver Verbindungen. In diesem Fall werden neue Verbindungen geschlossen, wenn sie in den Verbindungspool aufgenommen werden, wodurch die Verbindungen zu Kurzverbindungen werden und die Serviceleistung weiter verschlechtert wird. Um diese Situation zu vermeiden, können die folgenden Optimierungsmaßnahmen ergriffen werden.

Setzen Sie maxIdleConns im Voraus auf einen größeren Wert, um kurze Verbindungen zu vermeiden

Trennen Sie MySQL-Lesen und -Schreiben gründlich

Verbessern Sie den MySQL-Durchsatz: Optimieren Sie die zurückgegebenen Felder, geben Sie keine unnötigen Felder zurück und verwenden Sie Verbindungen schnell wieder.

Der Paketdurchsatz sollte nicht zu groß sein, um eine Paketfragmentierung zu vermeiden.

Optimieren Sie den Verbindungspool. Wenn die Anzahl der Verbindungen vom Client zu MySQL größer ist als die maximale Anzahl an Leerlaufverbindungen, kann die Schließung verzögert werden (offiziell nicht unterstützt, kann wahrscheinlich nur von Ihnen selbst implementiert werden)

Am besten ist es, Leseanfragen nicht in MySQL zu platzieren, sondern in redis

6 Testcode

https://github.com/gotomicro/test/tree/main/gorm

Oben finden Sie ausführliche Informationen zu den Gründen, warum MySQLs MaxIdleConns unvernünftig ist und zu einer Kurzverbindung führt. Weitere Informationen zu MySQLs MaxIdleConns-Unvernünftigkeit finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!