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

Kernel

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.

( snitt_ | 2009. 01. 15., cs – 16:05 )

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)

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.

( LGee | 2009. 01. 15., cs – 19:29 )

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.

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.

( zdesigner | 2009. 01. 15., cs – 21:15 )

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. :)

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 :)

( vmiklos | 2009. 01. 16., p – 02:38 )

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''

( ubul_ | 2009. 01. 16., p – 07:55 )

É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.

( hyper80 | 2009. 01. 16., p – 09:27 )

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...

( saxus | 2009. 01. 16., p – 12:47 )

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