Hohe CPU-Last durch MySQL Heute Nachmittag habe ich ein Problem mit hoher Serverauslastung entdeckt, das durch MySQL verursacht wurde. Der Hintergrund des Problems ist wie folgt: Auf einem neuen Server wurde eine neue MySQL-Instanz erstellt. Es gab zwar nur einen MySQL-Prozess auf dem Server, aber die CPU-Last blieb hoch. Die Ergebnisse der Top-Befehlsabfrage waren wie folgt: [dba_mysql@dba-mysql ~]$ nach oben oben – 17:12:44, 104 Tage, 20 Minuten, 2 Benutzer, durchschnittliche Auslastung: 1,06, 1,02, 1,00 Aufgaben: 218 insgesamt, 1 läuft, 217 schläft, 0 angehalten, 0 Zombie Cpu0: 0,3 % us, 0,0 % sy, 0,0 % ni, 99,7 % id, 0,0 % wa, 0,0 % hi, 0,0 % si, 0,0 % st Cpu1: 0,3 % us, 0,0 % sy, 0,0 % ni, 99,7 % id, 0,0 % wa, 0,0 % hi, 0,0 % si, 0,0 % st Cpu2: 0,0 % us, 0,0 % sy, 0,0 % ni, 100,0 % id, 0,0 % wa, 0,0 % hi, 0,0 % si, 0,0 % st Cpu3: 0,3 % us, 0,0 % sy, 0,0 % ni, 99,7 % id, 0,0 % wa, 0,0 % hi, 0,0 % si, 0,0 % st Cpu4: 0,3 % us, 0,0 % sy, 0,0 % ni, 99,7 % id, 0,0 % wa, 0,0 % hi, 0,0 % si, 0,0 % st Cpu5: 0,0 % us, 0,0 % sy, 0,0 % ni, 100,0 % id, 0,0 % wa, 0,0 % hi, 0,0 % si, 0,0 % st Cpu6: 100,0 % us, 0,0 % sy, 0,0 % ni, 0,0 % id, 0,0 % wa, 0,0 % hi, 0,0 % si, 0,0 % st Cpu7: 0,0 % us, 0,0 % sy, 0,0 % ni, 100,0 % id, 0,0 % wa, 0,0 % hi, 0,0 % si, 0,0 % st Speicher: 16318504k gesamt, 7863412k genutzt, 8455092k frei, 322048k Puffer Swap: 5242876k insgesamt, 0k verwendet, 5242876k frei, 6226588k zwischengespeichert PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL 75373 mysql 20 0 845 m 699 m 29 m S 100,0 4,4 112256:10 mysqld 43285 Wurzel 20 0 174m 40m 19m S 0,7 0,3 750:40,75 Konsul 116553 Wurzel 20 0 518 m 13 m 4200 S 0,3 0,1 0:05,78 Falke-Agent 116596 niemand 20 0 143m 6216 2784 S 0,3 0,0 0:00.81 Python 124304 dba_mysq 20 0 15144 1420 1000 R 0,3 0,0 0:02.09 oben 1 Wurzel 20 0 21452 1560 1248 S 0,0 0,0 0:02,43 init Aus den obigen Ergebnissen können wir ersehen, dass unter den 8-Kern-CPUs nur ein Kern eine Auslastung von 100 % aufweist, während die anderen alle 0 % haben. Das Ergebnis der Sortierung nach CPU-Auslastung zeigt auch, dass der mysqld-Prozess mehr CPU belegt. Dieses Problem war mir noch nie begegnet. Meine erste Reaktion war, mich zu fragen, ob es irgendwelche Probleme auf Unternehmensebene gab, wie etwa einige langsame Abfragen, die ständig CPU-Ressourcen beanspruchten. Also loggte ich mich bei MySQL ein und verwendete „show processlist“, um den aktuellen Prozess anzuzeigen. Ich stellte fest, dass außer einigen Aktualisierungsvorgängen keine anderen SQL-Anweisungen ausgeführt wurden. Also habe ich mir das Slow-Log noch einmal angesehen und festgestellt, dass die Ausführungszeit der SQL-Anweisungen im Slow-Log sehr kurz war. Die meisten davon waren darauf zurückzuführen, dass keine Indizes verwendet wurden. Die Anzahl der gescannten Datensätze war jedoch sehr gering, nur ein paar hundert Zeilen. Auf Geschäftsebene schien es kein Problem zu geben. Nachdem wir Probleme auf Unternehmensebene ausgeschlossen haben, schauen wir uns nun Probleme auf Datenbankebene an. Nach einem Blick auf den Pufferpool sehen wir, dass der Wert lautet: [email protected]:(keine) 17:20:35>>Variablen wie „%pool%“ anzeigen; +-------------------------------------+----------------+ | Variablenname | Wert | +-------------------------------------+----------------+ | innodb_buffer_pool_chunk_size | 5242880 | | innodb_buffer_pool_dump_at_shutdown | EIN | | innodb_buffer_pool_dump_now | AUS | | innodb_buffer_pool_dump_pct | 25 | | innodb_buffer_pool_Dateiname | ib_buffer_pool | | innodb_buffer_pool_instances | 1 | | innodb_buffer_pool_load_abort | AUS | | innodb_buffer_pool_load_at_startup | EIN | | innodb_buffer_pool_load_now | AUS | | innodb_buffer_pool_size | 5242880 | | Thread_Pool_High_Prio_Mode | Transaktionen | | thread_pool_high_prio_tickets | 4294967295 | | Threadpool-Leerlaufzeitüberschreitung | 60 | | Threadpool_max_Threads | 100000 | | Threadpool_Überabonnement | 3 | | Threadpoolgröße | 8 | | Threadpool-Stalllimit | 500 | +-------------------------------------+----------------+ 17 Zeilen im Satz (0,01 Sek.) Aus diesem Ergebnis ist ersichtlich, dass die Pufferpoolgröße nur 5 M beträgt, was definitiv ein Problem darstellt. Normalerweise beträgt der Pufferpool der Online-Umgebung 1 G oder mehr. Also habe ich die Konfigurationsdatei my.cnf überprüft und festgestellt, dass beim Start dieser Instanz die Einstellung innodb_buffer_pool_size 0 M betrug. Ja, Sie haben richtig gelesen, es waren 0 M. Hier müssen wir einen weiteren Parameter erwähnen. Wir können sehen, dass die Größe von innodb_buffer_pool_size dieselbe ist wie die Größe von innodb_buffer_pool_chunk_size. Das Konzept von Chunk ist ein Speicherblock, d. h. jedes Mal, wenn ein Pufferpool beantragt wird, wird dies in Einheiten von „Speicherblöcken“ beantragt. Ein Pufferpool enthält mehrere Speicherblöcke, daher muss die Pufferpoolgröße ein ganzzahliges Vielfaches der Chunk-Größe sein. Da der Wert von innodb_buffer_pool_chunk_size selbst 5 M beträgt, wird seine Größe automatisch auf ein Vielfaches von 5 M festgelegt, wenn wir ihn auf 0 M setzen. Daher beträgt unser innodb_buffer_pool_size-Wert 5 M. Da der Pufferpoolwert relativ klein ist, werde ich ihn auf 1 G ändern, um zu sehen, ob dieses Problem weiterhin auftritt: [email protected]:(keine) 17:20:41>>globale innodb_buffer_pool_size=1073741824 festlegen; Abfrage OK, 0 Zeilen betroffen, 1 Warnung (0,00 Sek.) [email protected]:(keine) 17:23:34>>Variablen wie „%pool%“ anzeigen; +-------------------------------------+----------------+ | Variablenname | Wert | +-------------------------------------+----------------+ | innodb_buffer_pool_chunk_size | 5242880 | | innodb_buffer_pool_dump_at_shutdown | EIN | | innodb_buffer_pool_dump_now | AUS | | innodb_buffer_pool_dump_pct | 25 | | innodb_buffer_pool_Dateiname | ib_buffer_pool | | innodb_buffer_pool_instances | 1 | | innodb_buffer_pool_load_abort | AUS | | innodb_buffer_pool_load_at_startup | EIN | | innodb_buffer_pool_load_now | AUS | | innodb_buffer_pool_size | 1074790400 | | Thread_Pool_High_Prio_Mode | Transaktionen | | thread_pool_high_prio_tickets | 4294967295 | | Threadpool-Leerlaufzeitüberschreitung | 60 | | Threadpool_max_Threads | 100000 | | Threadpool_Überabonnement | 3 | | Threadpoolgröße | 8 | | Threadpool-Stalllimit | 500 | +-------------------------------------+----------------+ 17 Zeilen im Satz (0,00 Sek.) Die Vorgehensweise ist wie oben beschrieben. Auf diese Weise ändern wir den Wert des Pufferpools auf 1 G. Der von uns festgelegte Wert ist 1073741824, aber der tatsächliche Wert wird 1074790400. Der Grund dafür wurde oben erwähnt, nämlich der Einfluss des Blockgrößenwerts. Verwenden Sie jetzt den Top-Befehl, um die CPU-Auslastung zu beobachten: [dba_mysql@dba-mysql ~]$ nach oben oben – 22:19:09, 104 Tage, 5:26, 2 Benutzer, durchschnittliche Auslastung: 0,45, 0,84, 0,86 Aufgaben: 218 insgesamt, 1 läuft, 217 schläft, 0 angehalten, 0 Zombie Cpu0: 0,3 % us, 0,3 % sy, 0,0 % ni, 99,3 % id, 0,0 % wa, 0,0 % hi, 0,0 % si, 0,0 % st Cpu1: 0,3 % us, 0,0 % sy, 0,0 % ni, 99,7 % id, 0,0 % wa, 0,0 % hi, 0,0 % si, 0,0 % st Cpu2: 1,0 % us, 0,0 % sy, 0,0 % ni, 99,0 % id, 0,0 % wa, 0,0 % hi, 0,0 % si, 0,0 % st Cpu3: 1,0 % us, 0,0 % sy, 0,0 % ni, 99,0 % id, 0,0 % wa, 0,0 % hi, 0,0 % si, 0,0 % st Cpu4: 0,3 % us, 0,3 % sy, 0,0 % ni, 99,3 % id, 0,0 % wa, 0,0 % hi, 0,0 % si, 0,0 % st Cpu5: 0,3 % us, 0,0 % sy, 0,0 % ni, 99,7 % id, 0,0 % wa, 0,0 % hi, 0,0 % si, 0,0 % st Cpu6: 0,0 % us, 0,3 % sy, 0,0 % ni, 99,7 % id, 0,0 % wa, 0,0 % hi, 0,0 % si, 0,0 % st Cpu7: 0,7 % us, 0,0 % sy, 0,0 % ni, 99,3 % id, 0,0 % wa, 0,0 % hi, 0,0 % si, 0,0 % st Speicher: 16318504k gesamt, 8008140k genutzt, 8310364k frei, 322048k Puffer Swap: 5242876k insgesamt, 0k verwendet, 5242876k frei, 6230600k zwischengespeichert PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL 43285 Wurzel 20 0 174m 40m 19m S 1,0 0,3 753:07.38 Konsul 116842 Wurzel 20 0 202m 17m 5160 S 1,0 0,1 0:21,30 Python 75373 mysql 20 0 1966m 834m 29m S 0,7 5,2 112313:36 mysqld 116553 Wurzel 20 0 670 m 14 m 4244 S 0,7 0,1 0:44,31 Falke-Agent 116584 Wurzel 20 0 331m 11m 3544 S 0,7 0,1 0:37,92 python2.6 1 Wurzel 20 0 21452 1560 1248 S 0,0 0,0 0:02,43 init Es lässt sich feststellen, dass die CPU-Auslastung gesunken ist. Um zufällige Phänomene zu vermeiden, habe ich die Pufferpoolgröße wieder auf den ursprünglichen Wert von 5 M geändert und festgestellt, dass das vorherige Problem erneut auftrat. Mit anderen Worten, das Einrichten eines großen Pufferpools ist tatsächlich eine Lösung. An diesem Punkt ist das Problem gelöst, aber über einige Dinge, die diesem Problem zugrunde liegen, sollte man nachdenken. Warum führt ein kleiner Pufferpool dazu, dass die Auslastung einer der CPUs 100 % beträgt? Ein Grund, der mir einfällt, ist, dass der 5M-Pufferpool zu klein ist, was dazu führt, dass das Business-SQL beim Lesen von Daten häufig mit der Festplatte interagiert. Die Festplattengeschwindigkeit ist relativ langsam, sodass die IO-Last zunimmt und die CPU-Last zu hoch ist. Warum nur eine CPU eine relativ hohe Last hat und die anderen fast 0, muss möglicherweise überprüft werden. Wenn jemand es weiß, lassen Sie es mich bitte wissen. Oben finden Sie ausführliche Informationen zur Fehlerbehebung bei hoher CPU-Auslastung bei MySQL. Weitere Informationen zur hohen CPU-Auslastung bei MySQL finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM! Das könnte Sie auch interessieren:
|
<<: So erhalten Sie USB-Scannerdaten mit js
>>: So implementieren Sie die Formularvalidierung in Vue
Tab-Auswahlkarten werden auf echten Webseiten seh...
Inhaltsverzeichnis 1. Einleitung 2. Verwendung 1....
React unterscheidet sich von Vue. Es implementier...
Virtualisierung 1. Umwelt Centos7.3 Deaktivieren ...
Es gibt zwei Arten von Linux-Systemzeiten. (1) Ka...
Das mit dem offiziellen Docker-Register erstellte...
1. Umgebungsversion Docker-Version 19.03.12 cento...
1. Verwenden Sie Pseudoklassen, um die Hälfte des...
Vorwort Dieser Artikel beschreibt zwei Situatione...
Ein einfacher cooler Effekt, der mit CSS3-Animati...
Inhaltsverzeichnis Schritt 1: Installieren Sie no...
Vorwort Im Internet gibt es häufig Artikel, die v...
Software für virtuelle Maschinen: VMware Workstat...
Wenn Sie VMware Workstation zum Öffnen einer virt...