
Wann an Linux De Datebankserver gëtt onerwaart ofgebrach, an d'Ursaach muss erausfonnt ginn. Et kéinte verschidde Grënn dofir ginn. Zum Beispill, SIGSEGV - Echec wéinst engem Feeler am Backend Server. Awer dëst ass rar. Meeschtens leeft Dir einfach aus Plaatz oder Erënnerung. Wann Dir keng Plaatz Plaz hutt, gëtt et nëmmen ee Wee eraus - fräi Plaz befreien an d'Datebank nei starten.
Out-Of-Memory Killer
Wann Dir Server oder de Prozess leeft ouni Späicher, Linux Den Out-Of-Memory Killer bitt zwou Léisungen: de ganze System ofbriechen oder de Prozess (Applikatioun) ofbriechen, deen de Speicher verbraucht. Et ass natierlech besser, de Prozess ofzebriechen an d'Betribssystem virum Ofstuerz ze retten. Kuerz gesot, ass den Out-Of-Memory Killer e Prozess, deen eng Applikatioun ofschléisst, fir de Kernel virum Ofstuerz ze retten. Hie verzicht op d'Applikatioun, fir d'Betribssystem lafen ze loossen. Loosst eis als éischt diskutéieren, wéi OOM funktionéiert a wéi een et kontrolléiere kann, an dann kucken, wéi den OOM Killer decidéiert, wéi eng Applikatioune ofgeschalt solle ginn.
Eng vun den Haaptaufgaben Linux — Speicher un Prozesser zouweisen, wa se en ufroen. Typesch freet e Prozess oder eng Applikatioun Speicher vum Betribssystem un, benotzt en awer net komplett. Wann de Betribssystem Speicher un all déi zouweist, déi en ufroen, awer net plangen, en ze benotzen, geet de System séier ouni Speicher, an de System crasht. Fir dëst ze verhënneren, reservéiert de Betribssystem Speicher fir e Prozess, awer verdeelt en net wierklech. Speicher gëtt nëmmen zougewisen, wann e Prozess en tatsächlech benotze wëll. Heiansdo huet de Betribssystem kee fräie Speicher, awer et verdeelt Speicher un e Prozess, a wann de Prozess en brauch, verdeelt de Betribssystem en, wa méiglech. Den Nodeel ass, datt de Betribssystem heiansdo Speicher reservéiert, awer wann et gebraucht gëtt, kee fräie Speicher ass, wat zu engem Systemcrash féiert. OOM spillt eng Schlësselroll an dësem Szenario andeems et Prozesser ofschléisst, fir ze verhënneren, datt de Kernel a Panik geet. Wann de PostgreSQL-Prozess gezwongen ofgebrach gëtt, erschéngt déi folgend Meldung am Logbuch:
Out of Memory: Killed process 12345 (postgres).Wann de System wéineg Erënnerung ass an et kann net befreit ginn, gëtt d'Funktioun genannt out_of_memory. Op dëser Etapp huet si just nach eng Saach ze maachen - een oder méi Prozesser ofzeschléissen. Sollt OOM-Killer de Prozess direkt ofschléissen oder kann et waarden? Natierlech, wann out_of_memory genannt gëtt, ass et wéinst der Waarde op eng I/O Operatioun oder Paging op Disk. Dofir muss den OOM Killer als éischt Kontrollen ausféieren an op Basis vun hinnen entscheeden datt de Prozess muss ofgeschloss ginn. Wann all d'Schecken hei ënnen positiv sinn, wäert OOM de Prozess ofschléissen.
Prozess Auswiel
Wann Erënnerung leeft aus, der Funktioun genannt out_of_memory(). Et huet eng Funktioun select_bad_process(), déi eng Evaluatioun vun der Funktioun kritt badness(). De "schlëmmste" Prozess gëtt gezielt. Funktioun badness() wielt e Prozess no bestëmmte Regelen.
- De Kernel brauch e Minimum Erënnerung fir sech selwer.
- Dir musst vill Erënnerung befreien.
- Et gëtt kee Besoin fir Prozesser ofzeschléissen déi wéineg Erënnerung benotzen.
- Minimum Prozesser mussen ofgeschloss ginn.
- Komplex Algorithmen déi d'Chancen fir d'Réalisatioun vun deene Prozesser erhéijen, déi de Benotzer selwer wëll fäerdeg bréngen.
Nodeems Dir all dës Kontrollen ofgeschloss hutt, iwwerpréift OOM de Score (oom_score). OOM ernannt oom_score all Prozess, an multiplizéiert dann dëse Wäert mat der Quantitéit vun Erënnerung. Prozesser mat méi grousse Wäerter si méi wahrscheinlech Affer vum OOM Killer ze falen. Prozesser, déi mam Root-Benotzer verbonne sinn, hunn e méi nidderegen Score a si manner wahrscheinlech gezwongen opzehalen.
postgres=# SELECT pg_backend_pid();
pg_backend_pid
----------------
3813
(1 row)De Postgres Prozess ID ass 3813, also an enger anerer Shell ass et méiglech de Score mat dësem Kernelparameter ze kréien oom_score:
vagrant@vagrant:~$ sudo cat /proc/3813/oom_score
2Wann Dir net wëllt datt OOM-Killer de Prozess iwwerhaapt ëmbréngt, gëtt et eng aner Kerneloptioun: oom_score_adj. Füügt e groussen negativen Wäert fir d'Chancen ze reduzéieren fir e Prozess ze kompletéieren deen Dir schätzt.
sudo echo -100 > /proc/3813/oom_score_adjFir e Wäert ze setzen oom_score_adj, setzen OOMScoreAdjust am Serviceblock:
[Service]
OOMScoreAdjust=-1000Oder benotzen oomprotect an engem Team rcctl.
rcctl set <i>servicename</i> oomprotect -1000Force Enn vun engem Prozess
Wann een oder méi Prozesser schonn ausgewielt sinn, rifft OOM-Killer d'Funktioun oom_kill_task(). Dës Funktioun schéckt en Ennsignal un de Prozess. Am Fall vun Erënnerung Mangel oom_kill() Rufft dës Funktioun fir e SIGKILL Signal un de Prozess ze schécken. E Message gëtt an de Kernel Log geschriwwe.
Out of Memory: Killed process [pid] [name].Wéi kontrolléiert OOM-Killer
В Linux Dir kënnt OOM-Killer aktivéieren oder deaktivéieren (obwuel déi lescht net recommandéiert ass). Fir en z'aktivéieren oder ze deaktivéieren, benotzt de Parameter vm.oom-kill. Fir OOM-Killer beim Runtime z'aktivéieren, lafen de Kommando sysctl.
sudo -s sysctl -w vm.oom-kill = 1Fir OOM-Killer auszeschalten, spezifizéiert de Wäert 0 am selwechte Kommando:
sudo -s sysctl -w vm.oom-kill = 0D'Resultat vun dësem Kommando gëtt net fir ëmmer gespäichert, awer nëmmen bis den éischte Restart. Wann Dir méi Persistenz braucht, füügt dës Linn an d'Datei /etc/sysctl.conf:
echo vm.oom-kill = 1 >>/etc/sysctl.confEng aner Manéier fir z'aktivéieren an auszeschalten ass eng Variabel ze schreiwen panic_on_oom. De Wäert kann ëmmer iwwerpréift ginn /proc.
$ cat /proc/sys/vm/panic_on_oom
0Wann Dir de Wäert op 0 setzt, da wann d'Erënnerung aus ass, gëtt et keng Kernelpanik.
$ echo 0 > /proc/sys/vm/panic_on_oomWann Dir de Wäert op 1 setzt, da wann d'Erënnerung aus ass, wäert eng Kernel Panik optrieden.
echo 1 > /proc/sys/vm/panic_on_oomOOM-Killer kann un- an ausgeschalt ginn, wéi mir scho gesot hunn. Linux kann méi Späicher fir Prozesser reservéieren wéi verfügbar ass, awer en net tatsächlech allokéieren, an dëst Verhalen gëtt vun engem Kernelparameter kontrolléiert LinuxD'Variabel ass dofir verantwortlech. vm.overcommit_memory.
Dir kënnt déi folgend Wäerter fir et uginn:
0: De Kernel selwer entscheet ob ze vill Späicher reservéiert soll ginn. Dëst ass de Standardwäert an de meeschte Versiounen. Linux.
1: De Kärel wäert ëmmer extra Erënnerung reservéieren. Dëst ass geféierlech, well d'Erënnerung kann auslafen, well wahrscheinlech enges Daags d'Prozesser et erfuerderen.
2: de Kernel wäert net méi Erënnerung reservéieren wéi am Parameter spezifizéiert overcommit_ratio.
Mat dësem Parameter spezifizéiert Dir de Prozentsaz vun der Erënnerung déi erlaabt ass ze reservéieren. Wann et keng Plaz fir et ass, gëtt keng Erënnerung zougewisen, an d'Reservatioun gëtt refuséiert. Dëst ass déi sécherst Optioun recommandéiert fir PostgreSQL. OOM-Killer gëtt vun engem aneren Element beaflosst - d'Austauschfäegkeet, déi vun der Variabel kontrolléiert gëtt cat /proc/sys/vm/swappiness. Dës Wäerter soen de Kärel wéi de Paging behandelt gëtt. Wat méi héich de Wäert ass, wat manner wahrscheinlech ass et datt OOM de Prozess ofschléisst, awer wéinst I/O Operatiounen huet et en negativen Impakt op d'Datebank. A vice versa - wat méi niddereg de Wäert ass, wat méi héich ass d'Wahrscheinlechkeet vun der OOM-Killer Interventioun, awer d'Datebankleistung ass och méi héich. De Standardwäert ass 60, awer wann déi ganz Datebank an d'Erënnerung passt, ass et besser de Wäert op 1 ze setzen.
Resultater
Loosst de "Killer" am OOM-Killer net Angscht maachen. An dësem Fall wäert de Killer de Retter vun Ärem System sinn. Et "killt" déi schlëmmste Prozesser a rett de System vum Crash. Fir ze vermeiden OOM-Killer ze benotzen fir PostgreSQL ofzeschléissen, setzt op vm.overcommit_memory Wäert 2. Dëst garantéiert net datt OOM-Killer net intervenéiere muss, awer et wäert d'Wahrscheinlechkeet reduzéieren fir de PostgreSQL-Prozess opzehalen.
Source: will.com
