MySQL-Slave löst Oom-Killer-Lösung_MySQL aus

In letzter Zeit erhalte ich häufig Alarmmeldungen wie „Nicht genügend Speicher in MySQL-Instanzen“. Wenn ich mich beim Server anmelde, stelle ich fest, dass MySQL 99 % des Speichers verbraucht hat.

Manchmal, wenn es nicht rechtzeitig verarbeitet wird, startet der Kernel MySQL für uns neu und dann können wir sehen, dass die dmesg-Informationen die folgenden Datensätze enthalten:

9. März 11:29:16 xxxxxx Kernel: mysqld hat oom-killer aufgerufen: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
9. März 11:29:16 xxxxxx Kernel: mysqld cpuset=/ mems_allowed=0
9. März 11:29:16 xxxxxx Kernel: Pid: 99275, Komm: mysqld Nicht tainted 2.6.32-431.el6.x86_64 #1
9. März 11:29:16 xxxxxx Kernel: Call Trace:

Beschreiben Sie nun die konkrete Szene:

Hauptvoraussetzung: Betriebssystem und MySQL-Version:

Betriebssystem: CentOS-Version 6.5 (endgültig) Kernel: 2.6.32-431.el6.x86_64 (physische Maschine)
MySQL: Percona 5.6.23-72.1-log (einzelne Instanz)

Trigger-Szenario: Beim Slave kommt es zu einem periodischen Speicheranstieg, unabhängig davon, ob andere Links eingehen, was den Kernel-Oom-Killer auslöst

Es wird gesagt, dass dieses Problem seit mehr als einem Jahr auftritt. Da ich gerade hierher gekommen bin, hat mich der Chef gebeten, noch einmal nachzusehen, ob ich irgendwelche Hinweise finden kann, also werde ich mit der Überprüfung dieses Problems beginnen:

1. Ich vermutete, dass der für MySQL zugewiesene Speicher unangemessen war, also überprüfte ich die Größe von innodb_buffer_pool und die Größe des physischen Speichers und stellte fest, dass die für BP zugewiesene Größe etwa 60 % des physischen Speichers ausmacht ist nicht der Grund, und es wurde behoben. Wenn dies das Problem war, hätten sie es schon vor langer Zeit entdecken müssen~
2. Überprüfen Sie die Parameterkonfiguration des Betriebssystems. [vm.swappiness = 1 ; /proc/sys/vm/overcommit_memory ; oom_adj ] Sie können den adj-Parameter vorübergehend auf -15 oder direkt auf -17 setzen, damit der Kernel MySQL niemals beendet Das Problem kann nicht grundsätzlich gelöst werden, und es bestehen bestimmte Risiken. Wird es dazu führen, dass MySQL hängen bleibt, wenn es Speicher benötigt, diesen aber nicht zuweisen kann? Denken Sie einfach über diese Methode nach.
3. Nun, die MySQL-Initialisierungsparameter und die Betriebssystemparameter scheinen keine unangemessene Konfiguration zu haben. Dann lasst uns nach MySQL selbst suchen!

Da der MySQL-Speicher stark ansteigt, wird er durch die Speicherzuweisung verursacht? Ich werde ihn auch in meiner Umgebung ausführen, nachdem im Internet gemeldet wurde: 1. Zeichnen Sie die vom aktuellen MySQL-Prozess belegte Speichergröße auf. 3. Führen Sie die Flush-Tabellen aus. 5. Zeichnen Sie die vom MySQL-Prozess belegte Größe auf Dies dient hauptsächlich dazu, festzustellen, ob sich der von MySQL zugewiesene Speicher vor und nach der Ausführung von Flush Table offensichtlich geändert hat. Nun, es scheint, dass dieser Fehler bei mir nicht mehr besteht.

Nachdem wir uns diese Version angesehen haben, gibt es auf der offiziellen Website auch einen Fehler bezüglich des MySQL OOM, der durch falsche Einstellungen von innodb_buffer_pool_instances und innodb_buffer_pool_size verursacht wird. Die allgemeine Bedeutung ist: Wir können innodb_buffer_pool_size größer einstellen Als unser tatsächlicher physischer Speicher beträgt unser physischer Speicher beispielsweise: 64 GB, und wenn wir innodb_buffer_pool_size = 300 GB und innodb_buffer_pool_instances > 5 festlegen, können wir MySQL weiterhin aufrufen. Allerdings ist MySQL anfällig für OOM. Detaillierte Informationen: http://bugs.mysql.com/bug.php?id=79850 Schauen Sie hier vorbei.

Es gibt eine andere Situation, in der ein Fehler gemeldet wurde. Das heißt, wenn der Slave die Filterung einstellt, löst er auch OOM aus, aber diese Instanzen sind nicht festgelegt, daher werde ich dies ignorieren.

Da es nicht durch eine Überbelegung des MySQL-Speichers verursacht wird, wird es auch nicht durch das Handle der offenen Tabelle verursacht. Welche anderen Gründe gibt es also?

Lassen Sie uns noch einmal darüber nachdenken. Die Master- und Slave-Konfigurationen sind identisch. Es ist nur so, dass der Master das Produktionsgeschäft ausführt, während einige Instanzen das Abfragegeschäft ausführen. Wenn Sie überhaupt keine Aufgaben ausführen, aber trotzdem OOM starten, liegt diese Situation wahrscheinlich am Slave.

Dann habe ich ein Beispiel gefunden und es ausprobiert. Ich weiß nicht, ob ich es nicht ausprobiert habe. Ich ging nach oben und führte es aus: Stop Slave; Start Slave; dieser Befehl blieb etwa 3 Minuten lang hängen. Nach der Überprüfung der Speichernutzung wurden 20 GB+ auf einmal freigegeben. An diesem Punkt haben wir im Grunde das Problem lokalisiert, aber wir alle wissen, dass Slave zwei Threads hat. Wird es durch SQL Thread oder IO Thread verursacht? Wir müssen noch auf weitere Untersuchungen warten, wenn es das nächste Mal passiert.

Veröffentlichen Sie einige Informationen zur Speicherüberwachung:

12:00:01 Uhr kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit
14:40:01 Uhr 566744 131479292 99,57 88744 618612 132384348 89,19
14:50:01 Uhr 553252 131492784 99,58 83216 615068 132406792 89,20
15:00:01 Uhr 39302700 92743336 70,24 95908 925860 132413308 89,21
15:10:01 Uhr 38906360 93139676 70,54 109264 1292908 132407836 89,21
15:20:01 Uhr 38639536 93406500 70,74 120676 1528272 132413136 89,21

Ich habe hier etwas spezifischere Dinge aufgezeichnet: https://bugs.launchpad.net/percona-server/bug/1560304 Wenn Sie nicht darauf zugreifen können, können Sie darauf zugreifen (http://www.bitsCN.com /article/ 88729.htm)

Zum Schluss noch eine kleine Zusammenfassung:

Phänomene: Sklaven-OOM
Vorübergehende Lösung: Slave neu starten
Langfristige Lösung: Nebenversions-Upgrade von MySQL Server

Für einen systematischeren Blick lesen Sie bitte, was Herr Guo geschrieben hat:
http://www.bitsCN.com/article/88726.htm
http://www.bitsCN.com/article/88727.htm