So legen Sie die Anzahl der MySQL-Verbindungen fest und ermitteln sie

Holen Sie sich die Anzahl der Verbindungen

--- Holen Sie sich die maximale Anzahl an Verbindungen. SHOW VARIABLES LIKE '%max_connections%'; 

--- Holen Sie sich die Verbindungsliste SHOW PROCESSLIST; 
--- Holen Sie sich die Verbindungsliste. VOLLSTÄNDIGE PROZESSLISTE ANZEIGEN. 

--- Aktuelle Verbindungsinformationen abrufen. Threads_connected ist die aktuelle Anzahl der Verbindungen. SHOW STATUS LIKE 'Threads%';

--- Erhalten Sie Verbindungsstatistiken wie die maximale Anzahl historischer Verbindungen und die maximale Verbindungsdauer usw. SHOW STATUS LIKE '%Connection%';

mysql> STATUS ANZEIGEN WIE 'Threads%';
+---------------------+------+
| Variablenname | Wert |
+---------------------+------+
| Threads_cached | 58 |
| Threads_connected | 57 | --- Dieser Wert bezieht sich auf die Anzahl der offenen Verbindungen | Threads_created | 3676 |
| Threads_running | 4 | ---Dieser Wert bezieht sich auf die Anzahl der aktivierten Verbindungen, die im Allgemeinen viel niedriger ist als der verbundene Wert+-------------------+----------+

Threads_connected ist dasselbe wie das Ergebnis von show processlist und gibt die aktuelle Anzahl der Verbindungen an. Genauer gesagt stellt Threads_running die aktuelle Anzahl gleichzeitiger

Festlegen der Anzahl der Verbindungen

Temporäre Einstellungen

mysql>show variables like 'max_connections'; --- Prüfen Sie die aktuelle maximale Anzahl von Verbindungenmsyql>set global max_connections=1000; --- Setzen Sie die maximale Anzahl von Verbindungen auf 1000 und prüfen Sie erneut, ob die Einstellung erfolgreich warmysql>exit --- Beenden

Permanente Einstellungen können die maximale Anzahl an Datenbankverbindungen in /etc/my.cnf festlegen

[mysqld]
max_Verbindungen = 1000

Verbindungspooleinstellungen im Projekt

Die folgende Formel wird von PostgreSQL bereitgestellt, das zugrunde liegende Prinzip bleibt jedoch unverändert und ist auf die meisten Datenbankprodukte auf dem Markt anwendbar. Außerdem sollten Sie den erwarteten Datenverkehr simulieren und mithilfe der folgenden Formel einen angemessenen Wert festlegen. Anschließend können Sie den Wert im tatsächlichen Test feinabstimmen, um die am besten geeignete Verbindungsgröße zu ermitteln.

Anzahl der Verbindungen = ((Anzahl der Kerne * 2) + Anzahl der verfügbaren Festplatten)

Die Anzahl der Kerne sollte kein Hyperthreading enthalten, selbst wenn Hyperthreading aktiviert ist. Wenn alle Hot Data zwischengespeichert werden, beträgt die tatsächliche Anzahl der effektiven Datenträger 0. Wenn die Cache-Trefferquote abnimmt, nähert sich die effektive Anzahl der Datenträger allmählich der tatsächlichen Anzahl der Datenträger an. Beachten Sie auch, dass nicht klar ist, wie gut diese Formel auf SSDs funktioniert.
Wenn Ihre Server-CPU ein 4-Core i7 ist, sollte die Verbindungspoolgröße dieser Formel zufolge ((4*2)+1)=9 betragen.

Lassen Sie uns auf 10 aufrunden. Ist das für Sie in Ordnung? 10 ist zu klein!

Wenn Sie der Meinung sind, dass es nicht funktioniert, können Sie einen Leistungstest durchführen. Wir garantieren, dass es problemlos 3.000 Benutzer gleichzeitig unterstützt, die einfache Abfragen mit einer Geschwindigkeit von 6.000 TPS ausführen. Sie können die Größe des Verbindungspools auch auf über 10 erhöhen. Ab diesem Punkt werden Sie feststellen, dass die Reaktionszeit zunimmt und die TPS zu sinken beginnt.

Was Sie brauchen, ist ein kleiner Verbindungspool und eine Warteschlange von Threads, die auf Verbindungen warten

Angenommen, Sie haben 10.000 gleichzeitige Zugriffe und legen die Größe des Verbindungspools auf 10.000 fest. Dann verschwenden Sie wahrscheinlich Ihre Zeit.

Ändern Sie es auf 1000, zu hoch? Auf 100 ändern? Immer noch zu viele.

Sie benötigen nur einen Datenbankverbindungspool der Größe 10 und können dann die verbleibenden Geschäftsthreads in der Warteschlange warten lassen.

Die Anzahl der Verbindungen im Verbindungspool sollte auf die Anzahl der Abfrageaufgaben eingestellt werden, die die Datenbank effektiv gleichzeitig ausführen kann (normalerweise nicht mehr als 2*Anzahl der CPU-Kerne).

Sie werden häufig einige Webanwendungen mit nicht sehr vielen Benutzern sehen, bei denen der Datenbankverbindungspool auf 100 oder 200 eingestellt ist, um mit etwa zehn gleichzeitigen Benutzern zurechtzukommen. Bitte überdimensionieren Sie Ihren Datenbankverbindungspool nicht.

Stimmt es, dass es besser ist, je näher man sich ist?

Simulieren Sie 9600 gleichzeitige Threads, um die Datenbank zu betreiben, und schlafen Sie zwischen jedem Datenbankvorgang 550 ms lang. Beachten Sie, dass die zu Beginn des Videos festgelegte Thread-Pool-Größe 2048 beträgt.

Werfen wir einen Blick auf die Ergebnisse des Leistungstests bei einer Datenbankverbindungspoolgröße von 2048:

Jede Anforderung muss 33 ms in der Warteschlange des Verbindungspools warten. Nach dem Herstellen der Verbindung dauert die Ausführung von SQL 77 ms, und die CPU-Auslastung bleibt bei etwa 95 %;

Als nächstes reduzieren wir die Größe des Verbindungspools auf 1024 und lassen die anderen Testparameter unverändert. Was ist das Ergebnis?

„Die Wartezeit zum Verbindungsaufbau bleibt dabei grundsätzlich unverändert, die SQL-Ausführungszeit verkürzt sich jedoch!“

Oh, es hat Fortschritte gegeben!

Als nächstes stellen wir ihn kleiner ein, reduzieren die Größe des Verbindungspools auf 96 und lassen andere Parameter wie die Anzahl gleichzeitiger Verbindungen unverändert, um zu sehen, was das Ergebnis ist:

Die durchschnittliche Wartezeit für jede Anforderung in der Warteschlange des Verbindungspools beträgt 1 ms und die SQL-Ausführungszeit 2 ms.

Oh mein Gott! Was zur Hölle?

Wir haben nichts optimiert, sondern lediglich die Größe des Datenbankverbindungspools reduziert. Dadurch konnte die durchschnittliche Antwortzeit von 100 ms auf 3 ms gesenkt werden. Der Durchsatz steigt exponentiell!

Du bist so gut!

Warum passiert das?

Überlegen wir einmal, warum Nginx intern nur 4 Threads verwendet, seine Leistung aber die von Apache HTTPD mit 100 Prozessen bei weitem übertrifft? Wenn wir über das Warum nachdenken, liegt die Antwort ziemlich auf der Hand, wenn wir an die Grundlagen der Informatik zurückdenken.

Sie sollten wissen, dass selbst ein Computer mit einer Single-Core-CPU Hunderte von Threads „gleichzeitig“ ausführen kann. Aber wir alle wissen, dass es sich dabei nur um einen Streich handelt, den uns das Betriebssystem spielt, indem es schnell zwischen Zeitscheiben wechselt.

Ein CPU-Kern kann jeweils nur einen Thread ausführen. Dann wechselt das Betriebssystem den Kontext und der CPU-Kern wird schnell für die Ausführung des Codes eines anderen Threads eingeplant. Dieser Vorgang wird immer wieder wiederholt, sodass die Illusion entsteht, dass alle Prozesse gleichzeitig ausgeführt werden.

Tatsächlich ist die sequentielle Ausführung von A und B auf einem Rechner mit einer Single-Core-CPU immer schneller als die „gleichzeitige“ Ausführung von A und B durch Time-Slicing-Switching. Wer den Betriebssystemkurs studiert hat, sollte den Grund dafür kennen. Wenn die Anzahl der Threads die Anzahl der CPU-Kerne überschreitet, wird das System durch das Hinzufügen weiterer Threads aufgrund der zusätzlichen Leistung, die durch den Kontextwechsel entsteht, nur langsamer und nicht schneller.

An diesem Punkt sollte es klar sein …

Oben finden Sie detaillierte Informationen zur Methode zum Festlegen und Abrufen der Anzahl von MySQL-Verbindungen. Weitere Informationen zum Festlegen und Abrufen der Anzahl von MySQL-Verbindungen finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!