Heim >Datenbank >MySQL-Tutorial >MySQL OOM System 2 OOM Killer_MySQL

MySQL OOM System 2 OOM Killer_MySQL

WBOY
WBOYOriginal
2016-08-20 08:48:121301Durchsuche

Dabei geht es um die Frage: Wer soll getötet werden? Im Allgemeinen reagieren Schüler, die ein wenig über den Linux-Kernel wissen, zuerst auf denjenigen, der ihn am häufigsten verwendet, und töten ihn. Dies ist natürlich ein wichtiger Faktor, den der Linux-Kernel zuerst berücksichtigt, aber das ist nicht ganz der Fall. Wir überprüfen einige Linux-Kernel-Informationen und können feststellen, dass tatsächlich durch /proc/1fd460db7b2c2eba732e7ab84276e0af/oom_score bestimmt wird, wer getötet wird. Dieser Wert ist für jeden Prozess einer und wird von der Funktion oom_badness() des Linux-Kernels berechnet. Lesen wir die Funktion badness() sorgfältig durch.

Im Kommentarteil der Funktion badness() wird die Verarbeitungsidee der Funktion badness() angegeben:

1) Wir verlieren den Mindestarbeitsaufwand
​ ​ 2) Wir stellen eine große Menge Speicher wieder her
3) Wir töten nichts Unschuldiges, indem wir Tonnen von Erinnerungen fressen
4) Wir wollen die minimale Anzahl an Prozessen (einen) beenden
5) Wir versuchen, den Prozess abzubrechen, den der Benutzer von uns erwartet. Dieser Algorithmus wurde sorgfältig abgestimmt, um dem Prinzip der geringsten Überraschung zu entsprechen ... (seien Sie vorsichtig, wenn Sie ihn ändern)

Im Allgemeinen geht es darum, die minimale Anzahl von Prozessen zu beenden, um die maximale Menge an Speicher zu erhalten, was damit übereinstimmt, dass wir den Prozess beenden, der die größte Menge an Speicher beansprucht.

/*
* Die Größe des Gedächtnisses des Prozesses ist die Grundlage für die Schlechtigkeit.
*/

Punkte = p->mm->total_vm;

Der Ausgangspunkt der Bewertung ist der tatsächlich vom Prozess verwendete RAM-Speicher. Beachten Sie, dass SWAP hier nicht enthalten ist, d. h. der OOM-Killer bezieht sich nur auf den tatsächlichen physischen Speicher des Prozesses und hat nichts damit zu tun Mit Swap können wir sehen, dass die tatsächliche Nutzung des Prozesses umso höher ist, je höher die Punktzahl ist, und je höher die Punktzahl, desto einfacher ist es, sie zu opfern.

/*
* Prozesse, die viele untergeordnete Prozesse verzweigen, sind wahrscheinlich
* eine gute Wahl. Wir fügen die VM-Größe der Kinder hinzu, wenn sie
* haben einen eigenen mm. Dadurch wird verhindert, dass Forking-Server die
überfluten * Maschine mit unendlich vielen Kindern
*/
...
If (chld->mm != p->mm && chld->mm)
Punkte = chld->mm->total_vm;

Dieser Absatz bedeutet, dass der vom untergeordneten Prozess belegte Speicher dem übergeordneten Prozess berechnet wird.

s = int_sqrt(cpu_time);
          wenn (s)
Punkte /= s;
        s = int_sqrt(int_sqrt(run_time));
          wenn (s)
Punkte /= s;

Dies zeigt, dass die Punktzahl umso niedriger ist und die Wahrscheinlichkeit, dass der Prozess abgebrochen wird, umso geringer ist, je länger die vom Prozess beanspruchte CPU-Zeit ist oder je länger der Prozess läuft.

/*
* Geschönte Prozesse sind höchstwahrscheinlich weniger wichtig, also doppelt
* ihre schlechten Punkte.
*/
If (task_nice(p) > 0)
Punkte *= 2;

Wenn die Prozesspriorität niedrig ist (guter Wert, positiver Wert ist niedrige Priorität, negativer Wert ist hohe Priorität), wird der Punkt verdoppelt.

       /*
        * Superuser-Prozesse sind normalerweise wichtiger, deshalb machen wir es
        * weniger wahrscheinlich, dass wir diese töten.
        */
        if (cap_t(p->cap_efficient) & CAP_TO_MASK(CAP_SYS_ADMIN) ||
                                p->uid == 0 || p->euid == 0)
                Punkte /= 4;

          super用户的进程优先级较低.

        /*
         * Wir wollen keinen Prozess mit direktem Hardwarezugriff beenden.
         * Das könnte nicht nur die Hardware, sondern normalerweise auch die Benutzer durcheinander bringen
         * neigen dazu, dieses Flag nur für Anwendungen zu setzen, die ihrer Meinung nach
sind          * genauso wichtig.
         */
        if (cap_t(p->cap_efficient) & CAP_TO_MASK(CAP_SYS_RAWIO))
                Punkte /= 4;

          直接可以访问原始设备的进程优先级较高.

        /*
         * Passen Sie die Punktzahl um oomkilladj an.
         */
        if (p->oomkilladj) {
                if (p->oomkilladj > 0)
                        Punkte 8428cef43a18c8ff27b763aa5f592054oomkilladj;
                sonst
                        Punkte >>= -(p->oomkilladj);

        }

每个进程有个oomkilladj j Alter 15, Jahr-17, 越大越容易被干掉, 这个值由于是移位运算,所以影响还是比较大的.

下面我写个小程序实验一下:

 #define MEGABYTE 1024*1024*1024
 #include <stdio.h>
 #include <string.h>
 #include <stdlib.h>
 int main(int argc, char *argv[])
{
void *myblock = NULL;
myblock = (void *) malloc(MEGABYTE);
printf("Currently allocating 1GB\n");
sleep(1);
int count = 0;
while( count < 10)
{
 memset(myblock,1,100*1024*1024);
 myblock = myblock + 100*1024*1024;
 count++;
 printf("Currently allocating %d00 MB\n",count);
 sleep(10);
  }
  exit(0);
 }

Eine große Anzahl von 1G-Geräten, 100M-Geräten, 2G-Geräten, 400M-Geräte. Swap空间的机器上跑3个上面的进程.我们看一下运行结果:

   MySQL OOM 系统二 OOM Killer - 网易杭研后台技术中心 - 网易杭研后台技术中心的博客

)。

    

MySQL OOM 系统二 OOM Killer - 网易杭研后台技术中心 - 网易杭研后台技术中心的博客

    当物理内存空间不足时,OS开始进行Swap,可用的Swap空间开始减少.

   

MySQL OOM 系统二 OOM Killer - 网易杭研后台技术中心 - 网易杭研后台技术中心的博客     

 掉,同时oom_score为1000.

     这3个进程的oom_adj的效果。重新启动3个进程,然后我们看到test2的PID是12640

MySQL OOM 系统二 OOM Killer - 网易杭研后台技术中心 - 网易杭研后台技术中心的博客

Lassen Sie uns die folgende Anweisung ausführen

echo 15 > /proc/12640/oom_adj

Nach einer Weile stellten wir fest, dass der Swap-Speicherplatz stark abnahm und im Grunde der OS OOM_Killer kurz vor dem Start stand.

MySQL OOM 系统二 OOM Killer - 网易杭研后台技术中心 - 网易杭研后台技术中心的博客

Tatsächlich wurde der 12640-Prozess erwartungsgemäß abgebrochen.

Um zu verhindern, dass der von Ihnen benötigte Prozess abgebrochen wird, können Sie dies tun, indem Sie den oom_adj des Prozesses festlegen. Natürlich werden einige Leute sagen, dass dies alles durch Überbuchung verursacht wird. Da Linux overcommit_memory zum Deaktivieren der Overcommit-Funktion bereitstellt, warum nicht auch deaktivieren? Dies hat Vor- und Nachteile. Sobald die Überbelegung deaktiviert ist, bedeutet dies, dass MySQL nicht mehr Speicherplatz als den tatsächlichen Speicher beantragen kann. Wenn die Anwendung nicht angewendet werden kann, stürzt dies ab. Dies erhöht die erforderliche Zeit erheblich. Das Risiko von MySQL-Ausfällen ist der Grund für die Überlastung von Linux.

Anhand der obigen Analyse ist es nicht schwer zu erkennen, dass MySQL im Allgemeinen das bevorzugte Objekt von OOM_Killer wird, wenn oom_adj nicht festgelegt ist, da MySQL im Allgemeinen den größten Speicher belegt. Wie können wir also als MySQL versuchen, das Risiko zu vermeiden, getötet zu werden? Im nächsten Kapitel werden wir uns darauf konzentrieren, zu analysieren, wie OOM aus der Perspektive von MySQL vermieden werden kann.

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn