oom_pardon, avagy ne öld meg az xlock-om

Címkék

Egy kis tanmese (forrás: LKML):

``Egy repülőgép-gyártó vállalt felfedezte, hogy olcsóbban lehet repülni, ha a repülőben kevesebb üzemanyag van. A repülőnek így kevesebb a súlya, kevesebbet fogyaszt, tehát pénzt spórol. Néhány esetben azonban előfordulhat, hogy az üzemanyag kevésnek bizonyul, és a repülő lezuhanhat. Ezt megelőzendő, a vállalat mérnökei kifejlesztettek egy speciális OOF (out-of-fuel) mechanizmust. Vész esetén a mechanizmus kiválaszt egy utast, és kidobja a repülőből (ha szükséges, akkor megismétli az eljárást). Nagy mennyiségű elmélet és lelkes publikáció született abból a célból, hogy megoldja a kidobásra jelölt ``helyes kiválasztásának'' problémáját. Az áldozat kiválasztása legyen random? Vagy válasszuk a legnehezebb személyt? Vagy a legöregebbet? Az utasok fizethetnek azért, hogy ne kerüljenek sorra, így a legszegényebbnek kell lennie az áldozatnak? Vagy amikor a legnehezebb személyt kell kiválasztani, akkor kivételt kell tenni abban az esetben, ha az a pilóta? Vagy az első osztályon utazókat kivételes esetnek kell kezelni? Az OOF mechanizmus elkészült, hébe-hóba aktiválódik olyankor is, mikor éppen nincs is üzemanyag-hiány. A mérnökök jelenleg azt vizsgálják, hogy pontosan hogyan történhetett ez az üzemzavar.''Thomas Habets egy oom_pardon patchel állt elő az LKML-en. Azt kérdezte a kernelfejlesztőktől, hogy mit szólnának ahhoz, ha lenne egy olyan sysctl amelyik azt csinálná, hogy ``az isten szerelmére, soha ne öld meg ezeket a processzeket, ha OOM van. Ha semmi mást nem tudsz megölni, legyen inkább (kernel)pánik.''

Példaként a /usr/bin/vlock és usr/X11R6/bin/xlock programokat hozta fel. Mint mondta, szerinte nagyon kellemetlen meglepetés az, amikor azért találja a gépét lezáratlanul, mert az OOM kinyírta az /usr/bin/vlock-ot.

Ezt kiküszöbölendő, készített egy patchet. A /proc/sys/vm/ alatt található egy olyan kapcsoló amellyel a VM alrendszer tudtára lehet hozni, hogy mely programok tabuk a processz kilövöldözéskor.

Példa:

echo "/usr/bin/vlock /usr/X11R6/bin/xlock" > /proc/sys/vm/oom_pardon

Ezzel a VM alrendszer tudomására hoztuk, hogy ha törik, ha szakad a vlock és xlock programoknak működniük kell, és ha olyan memóriahiányos állapot áll be, hogy az OOM killer ezeket a programokat akarná lelőni, akkor inkább pánikoljon el a rendszer.

A fejlesztőknek tetszett az ötlet, néhányan javaslatokat tettek a kód jobbá tételére.

Andrea Arcangeli -a Novell kernelhackere- elmondta, hogy már korábban kifejlesztettek egy hasonló működésű patchet a saját kernelük számára. A neve protect-pids. Mint mondta, az OOM killer-ben nem lehet megbízni mondjuk szerver környezetben, ahol a legnagyobb task az éppen az, aminek minden körülmények közt működnie kell. Hasznos lehet ez az elgondolás ott, ahol néhány ``trusted'' alkalmazást kell megvédeni...

A thread itt.

Hozzászólások

2.4.x-es kernelekhez lehet hasznalni az EMACS PROTECTOR -t aminek
hasonlo a funkcionalitasa

http://ignotus.hixsplit.hu/EmacsProtectorPatch.html

--
....sutongi tti olleh

Végre történik valami. Az a legviccesebb, mikor egy mail gateway-en az amavis-t és/vagy a clamd-t kilövi a kernel..... A levelek csak gyűlnek, gyűlnek....

Vegre. Nem szajtepes vagy cvs remove, hanem egy elfogadhato megoldas (1ebkent enis jartam igy xlock-al).

Valaki homályosítson már föl, hogy a (2.4-es szériában) default OOM metódus miért nem elég jó? A Configure.help szerint ott az van, hogy azt lövi ki, amelyik igényelt volna memóriát.

Adi> Valaki homályosítson már föl, hogy a (2.4-es szériában) default
Adi> OOM metódus miért nem elég jó? A Configure.help szerint ott az
Adi> van, hogy azt lövi ki, amelyik igényelt volna memóriát.

Azert mert igy az OOM killer gyakran pont azt a processt lovi ki amelyik
miatt az adott gep uzemeltetve van. Ha mar valamit kilo miert ne
lohetne' ki elobb a nem fontos dolgokat?

--
....sutongi tti olleh