MySQL OOM-Serie 3: Beseitigen Sie das Pech, dass MySQL getötet wurde_MySQL

In den beiden vorherigen Kapiteln haben wir die Speicherzuweisungsstrategie von Linux analysiert und das durch „Überbuchung“ verursachte Risiko durch die Verwendung des OOM_Killer-Mechanismus gelöst. MySQL kann wie andere Anwendungen auch innerhalb des vom Betriebssystem zugelassenen Bereichs überschritten werden Im Allgemeinen verstehen die meisten Leute, dass Innodb_buffer_pool kleiner als der tatsächliche physische Speicher sein muss, sonst kann MySQL nicht gestartet werden. Tatsächlich handelt es sich hierbei um ein Missverständnis. Dies wird nicht durch die Betriebssystemschicht (OS) gesteuert. Wenn „Überbuchung“ zulässig ist, kann Innodb_buffer_pool die tatsächliche Speicherplatzgröße weit überschreiten, dieser Teil des Speicherplatzes wird jedoch nicht genutzt. Wir können ein kleines Experiment durchführen, siehe Bild unten:

Der Innodb_buffer_pool von MySQL ist auf 5G eingestellt, der tatsächliche Speicher beträgt jedoch nur 3G.
Nachdem wir so viel gesagt haben, kehren wir zum Thema zurück und kehren zu dem Problem zurück, das wir zuerst erwähnt haben, nämlich dass die RDS-Instanz vom Betriebssystem beendet wird. Wir haben auch zuvor erwähnt, dass MySQL im Allgemeinen das erste sein wird, wenn der verfügbare Speicher der Instanz nicht ausreicht Wahlziel von OOM_Killer. Hier gibt es zwei Probleme:

1. Warum ist nicht genügend Speicher vorhanden?
2. Wie kann man MySQL aus dem Pech herausholen, getötet zu werden?
Schauen wir uns zunächst die erste Frage an. Es gibt viele Gründe für das Problem des unzureichenden Speichers, aber es gibt hauptsächlich zwei Aspekte. Der erste ist, dass es ein Problem mit der eigenen Speicherplanung von MySQL gibt. Der zweite Grund ist, dass Server, die im Allgemeinen MySQL bereitstellen, viele Überwachungs- oder geplante Aufgabenskripte bereitstellen und diesen Skripten oft die notwendigen Speicherbeschränkungen fehlen, was dazu führt, dass in Spitzenzeiten viel Speicher belegt wird, was den Linux-OOM_Killer-Mechanismus und MySQL auslöst ist unschuldig.
Wie können wir MySQL also aus dem Pech herausholen, getötet zu werden? Die Hauptursache für den Abbruch von MySQL liegt im überbuchten Speicherzuweisungsmechanismus von Linux. Wie bereits erwähnt, ist es unmöglich, das Risiko des Abbruchs einer bestimmten Anwendung vollständig zu vermeiden. Um zu verhindern, dass MySQL getötet wird, kann dem Betriebssystem nur die Zuweisung von Speicher über den tatsächlichen Speicherplatz hinaus untersagt werden. Wie bereits erwähnt, empfehlen wir dies jedoch nicht für Server, die mit MySQL bereitgestellt werden, da ein Großteil des MySQL-Speichers gerade erst beantragt wurde und nicht sofort verwendet wird. Sobald das Betriebssystem eine Überbuchung verhindert, wirkt sich dies nicht nur auf die Planung des MySQL-eigenen Speichers aus stellt strengere Anforderungen, außerdem besteht das Problem einer unzureichenden Speicherauslastung. Gleichzeitig wird der private Speicher jeder MySQL-Verbindung dynamisch zugewiesen. Wenn er nicht zugewiesen wird, führt dies direkt zum Absturz des Servers, was auch das Risiko eines MySQL-Absturzes erhöht.
Da es durch das Betriebssystem begrenzt ist und eine Zerstörung nicht vollständig vermeiden kann, können wir nur versuchen, die Wahrscheinlichkeit einer Zerstörung von MySQL zu verringern. Ich denke, wir können mindestens die folgenden 3 Dinge tun:

1) Planen Sie die Speichernutzung von MySQL angemessen.
2) Passen Sie den Parameter OOM_adj an, um die Priorität der Sperrung von MySQL durch OOM_Killer zu senken.
3) Verstärken Sie die Speicherüberwachung und Alarmierung. Sobald der DBA einen Alarm auslöst, sollte er schnell eingreifen und einige Verbindungen, die mehr Speicher belegen, unterbrechen.