"A Linux megölte Kenny-t! A rohadék!"

 ( trey | 2009. január 15., csütörtök - 16:01 )

Avagy nyírja ki az OOM Killer az a processzt, amelyiket mi akarjuk. Evgeniy Polyakov levele elég hosszú szálat generált a LKML-en. A fejlesztő szerint kiszámíthatatlan, hogy elfogyó memória esetén az Out Of Memory Killer melyik processzt vadássza le, és gyakran előfordul, hogy pont azt, amelyiket nem szeretnénk.

Szerinte jó lenne, ha meg lehetne határozni, hogy az OOM Killer melyik processzt áldozza fel először. Elkészített egy patch-et, amely lehetővé teszi a potenciális áldozatok nevének megadását.

Alapértelmezés szerint a fejlesztő a "Kenny" nevet adta meg (majd később alapértelmezetten üresre állította az értéket). Memóriahiány felléptekor az OOM Killer ezt nyírja ki először. Ha valaki mást áldozna fel, akkor az alábbi módon lehet megadni az áldozatot:

echo Java > /proc/sys/vm/oom_victim

A fejlesztők egy részének - például Alan Cox-nak - nem tetszik az elképzelés, mert szerinte van már erre sokkal jobban működő interfész a kernelben.

A bejelentés és a hosszú thread itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

via:

Hello,

I sometime use this script to tune the oom_adj on some server, so I
thought it would be good idea to share it. First column is the pid,
second is the oom_score, third is the executable name.

Thanks.

#!/bin/sh

# (C) SUSE, GPL'd

ls /proc/*/oom_score| grep -v self | \
sed 's/\(.*\)\/\(.*\)/echo -n "\1 "; \
echo -n "`cat \1\/\2 2>\/dev\/null` "; \
readlink \1\/exe || echo/'|sh |sort -nr +1

en ilyennel azert nem egetnem magam...

"sort: open failed: +1: No such file or directory"

'-k +2' -vel mukodik.

De hogy ne csak pofazzak:

#!/bin/bash

# (c) LGee, do whatever you want
# I feel sorry for your small window. To emphasize this, I kept the line breaks.

$ for i in $(ps --no-heading -eo pid) \
do echo $i $(ps --no-heading -o comm $i) \
$(sed '/self/d' /proc/$i/oom_score) \
done 2>/dev/null

Igen, a sort kimaradt, izles szerint hozzarakhato (bar akkor mar adja magat egy head / tail is, mert ugye kit erdekel a maradek 100-200 processz)

Egy meg gusztustalanabb verzio (OOM score tetszes szerint emelheto):

for i in $(ps --no-heading -eo pid); do if [[ $(sed '/self/d' /proc/$i/oom_score) -gt 1000 ]]; then echo $(ps --no-heading -o comm,pid $i); fi; done 2>/dev/null

Csak kötözködésileg: az echo $(ps) forma iszonyat gány, lévén az echo-val kiírod azt, amit a parancs kiírna. akkor már inkább csak simán ps mindenféle huncutság nélkül. (Mindezt csak azért, mert éppen memória túlterhelés ellen játszunk - akkor meg ne terheljük mi magunk.)

Ja... erre valok a szemfules kritikusok.

Amugy csak az eredetiben felhalmozott hihetetlen mennyisegu pipe miatt irtam le egyaltalan ezeket. Nem hiszem, hogy ne lenne egyszerubb a ps-nek gyartani egy ujabb opciot.

Ja, es ha nem echo-zom, akkor egy sorba tenni a harom lekerdezest tovabb bonyolitja a dolgot.

Csak az erdekesseg kedveert, AIX-en van ebben a temaban ket kernel-parameter (vmo):

nokilluid
Purpose: User IDs lower than this value are exempt from getting killed due to low page-space conditions.

Tehat ha 'olni kell', a root es egyeb rendszer-userek (alacsony UID) altal futtatott processzek megvedhetok. Kar, hogy a WebSphere rootkent fut...

npskill
Purpose: Specifies the number of free paging-space pages at which the operating system begins killing processes.

Ez pedig az a limit, ahol az operacios rendszer elkezd takaritani.

WebSphere-t nem szoktak root-kent inditani, sajat usert neki, ha mar muszaj hasznalni.

Ha-ha-ha. Tokeletesen egyetertek, de nem az en hataskorom.

A linuxos oom killer nem tud olyat, hogy megadható legyen a memória-limit (mondjuk %-ban), amikortól bekapcsoljon?
Épp a napokban vettem észre egy memory-leaket firefox alatt, ez kikapcsolt swap-nál kb. 10 percre lassítja használhatatlan sebességűre a rendszert, mielőtt az oom killer aktiválódna.

ulimit?

az mi? uj lehetsz errefele ha azt feltetelezed h a linux legalapvetobb mukodesevel tisztaban vannak az ide jarogato kompizguruk

Ez jól hangzik, köszi!

Hehe. Vicces volt, mikor a beadandómat írtam, megnyitott, természetesen mentetlen állapotban hagytam, közben futott egy rakás grafikus szarság, ami ette a memóriát, aztán elfordítottam a compizkockát, csináltam valami mást, még egy fordítás, átadtam másnak a gépem erőforrásai feletti irányítást :), majd mikor jöttem vissza, akkor upsz, a legtöbbet zabáló processzt kinyírtam az oomkiller. Tehát az X-et, így a gyerekprocesszeinek is annyi volt. Az ellen ez jól jött volna. :)

swap ez ellen nem véd??

volt, hogy azureus felette a ramomat és menet közben kellett alája raknom még egy adag swapot :)
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

Azt is megette.

Minek a swap akkor? De most tényleg. És olyat nem-e lehetne-e hogy aminek leggyorsabban emelkedik a memóriaigénye (potenciális memóriaszivárgás) azt lőjük ki először?

A swap a kevés memória ellen véd (az olcsó ramok korában ezért néha már kérdéses a léte, de ez egy nagyon más téma, inkább hagyjuk)
Viszont ha egy progi egyre csak több és több memóriát igényel (mondjuk egy bug miatt), akkor nincs az a memóriamennyiség, amit ne tudna felzabálni.

És mi van, ha kevés a szabad memória, majd elindítasz egy memóriaigényes progit, ami egyből elkezd mondjuk fájlokkal is dolgozni, és itt fogy el a memória - akkor ezt lője le az oom-killer, hogy aztán inkonzisztens adatokat hagyjon maga után?
Szóval nehéz megtalálni az optimális algoritmust.

Nekem most az jutott eszembe, hogy a leginkább humánus megoldás az lenne, ha egy processz átlép egy memórialimitet, akkor annak stop signált kéne küldeni (megállítva a további mem. zabálást), aztán majd a júzer eldönti, mi legyen vele (kinyirja ő, vagy valami mást zár be, és majd kézzel folytattatja a processzt stb.) Esetleg még grafikus user interfésszel is meg lehet spékelni, ami szól, hogy lenne egy parkolópályára tett processz, mi legyen vele. Na majd utánajárok, van-e már ilyesmi, vagy érdemes-e ilyet csinálni, és ha más nem, akkor akár még össze is dobok valamit :)

errol csak a regi al3x-fele emacs protector patch jutott eszembe, ami ennek az ellenkezojet csinalta. ;)

(mindent kilohet kiveve az emacs-et)

bar a description meg megvan, ignonak koszonhetoen:

,,Ha te is allando rettegesben elsz amiatt hogy a %$@#! Linux OOM killer barmikor kiloheti az Emacs-edet (holott az egesz PC nyilvanvaloan csak azert kell hogy az Emacs fusson valamin), akkor itt a megoldas: az Emacs protector kernel patch by al3x''

musthave stuff
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

foleg vim usereknek

nekik pont hogy nem :)
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

kilőjük az emacsot vimből, nem kell ide oom... :P

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

Én inkább egy olyan listát preferálnék prioritásokkal, ahol azt adhatjuk meg, mi az amit legutoljára nyírjon ki az oom killer. Asszem rövidebb lenne.

most látom, hogy már volt

Ez mar megvan a kernelben. Lasd lenti hozzaszolasom...

Igy a hozzaszolasokbol itelve nem sokan olvastatok bele a listaba.
Pedig eleg erdekes vita alakult ki ott, ennek a fenyeben valoban nem tunik olyan jo dolognak ez a patch.
A /proc/... PID .../oom_adj nekem is pontosabb/komolyabb interface-nek tunik. (PID alapjan megy, figyel a child processekre stb stb)
Ez a patch talan akkor lehet hasznos ha mondjuk epp fejlesztek egy progit, es egy végtelen ciklus miatt elszáll, és bezabálja a memóriát. Ilyenkor be lehetne irni a victim file-ba. De tapasztalat szerint ilyenkor 99% ban az oom killer magatol is megtalaja hogy ez a processz a bunos. Ugyhogy hajlok ra hogy Alan-eknak talan igaza van...

Mondjuk véleményem szerint a "nincs ram, csinálunk, bármi áron" elv szerintem továbbra is hülye elképzelés. Ha nincs, nincs, így járt az alkalmazás.

----------------
Lvl86 Troll

A kérdés csak az, hogy melyik alkalmazás jár így.

Szerintem fel van fújva az egész OOM-killeres ügy, nem hinném ennyi memóriában durván alulméretezett gép futkosna. Ha meg valami elszabadult, azt az OOM-killer eddig is hatékonyan azonosította.

mond ezt az sshd-nak, amikor be akarsz lepni, hogy megnezd, valojaban ki ette el a memoriat...

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Nekem az oom killer még sosem lőtte ki az ssh-t, pedig van pár netbootos gépem, amiben elég gyakran előfordul ilyen állapot, lévén nincs bennük diszk (és swap).
Igaz az egy másik oom killer, és butább is, mint a linuxos. :)

De akkor sem tudsz belepni, ha csak nincs eleg memoria egy uj shellnek vagy mar az sshnak se, hogy beleptessen.

Ilyenkor jön az oom-killer. :)