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.
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
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
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
WebSphere-t nem szoktak root-kent inditani, sajat usert neki, ha mar muszaj hasznalni.
- A hozzászóláshoz be kell jelentkezni
Ha-ha-ha. Tokeletesen egyetertek, de nem az en hataskorom.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
ulimit?
- A hozzászóláshoz be kell jelentkezni
az mi? uj lehetsz errefele ha azt feltetelezed h a linux legalapvetobb mukodesevel tisztaban vannak az ide jarogato kompizguruk
- A hozzászóláshoz be kell jelentkezni
Ez jól hangzik, köszi!
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
swap ez ellen nem véd??
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Azt is megette.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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 :)
- A hozzászóláshoz be kell jelentkezni
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''
- A hozzászóláshoz be kell jelentkezni
musthave stuff
---
/* No comment */
Ketchup elementál megidézése a sajt síkra
- A hozzászóláshoz be kell jelentkezni
foleg vim usereknek
- A hozzászóláshoz be kell jelentkezni
nekik pont hogy nem :)
---
/* No comment */
Ketchup elementál megidézése a sajt síkra
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
most látom, hogy már volt
- A hozzászóláshoz be kell jelentkezni
Ez mar megvan a kernelben. Lasd lenti hozzaszolasom...
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
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. :)
- A hozzászóláshoz be kell jelentkezni
De akkor sem tudsz belepni, ha csak nincs eleg memoria egy uj shellnek vagy mar az sshnak se, hogy beleptessen.
- A hozzászóláshoz be kell jelentkezni
Ilyenkor jön az oom-killer. :)
- A hozzászóláshoz be kell jelentkezni