Jaderné noviny - 1/2008 (diskuse)

[Filip Jirsák]

• první odstavec – „Zpoždění začíná to být spíše pravidlem“
• na konci 2.6.24-rc5, konečná verze do Vánoc nebude chybí konec spanu pro citaci

Nepoužívaly se dříve v JN správné české uvozovky „“?

Nehodilo by se pro citáty v JN používat sémantický tag <cite> a dám mu stejný styl, jako má třída kt_citace?

Jinak opět děkuji za další díl Jaderných novin.

[Robert Krátký]

Nepoužívaly se dříve v JN správné české uvozovky „“?

Spíše ne, ale je pravda, že bych to měl zavést u všech článků.

Nehodilo by se pro citáty v JN používat sémantický tag <cite> a dám mu stejný styl, jako má třída kt_citace?

Těch tagů, které by našly uplatnění, je více (q, samp, kbd, ...). Zkusím s nimi začít pracovat.

[kavol]

Kdykoliv začne OOM killer střílet, se systémem je něco špatně a je mnohem produktivnější to řešit, než si přát přesnějšího OOM killera.

nevím, jestli to není vytržené z kontextu, ale tak jak to stojí, tak bych řekl, že pisatel je s odpuštěním trouba - když je chyba v aplikaci (nebo třeba ani ne chyba, prostě jen zpracovává neobvykle velká data) a ta si naalokuje veškerou dostupnou paměť, takže systém jde do kytek, jak to podle něj mám řešit, to mám tu aplikaci přestat používat a odinstalovat, aby náhodou nedošlo na killer? nebo si mám napsat vlastního démona, který bude hlídat paměť a sestřelí, co jí žere kriticky mnoho, aby náhodou nedošlo na killer (neměla by to snad být jeho práce)?

[Filip Jirsák]

Kdykoliv začne OOM killer střílet, se systémem je něco špatně a je mnohem produktivnější to řešit, než si přát přesnějšího OOM killera.

nevím, jestli to není vytržené z kontextu, ale tak jak to stojí, tak bych řekl, že pisatel je s odpuštěním trouba - když je chyba v aplikaci (nebo třeba ani ne chyba, prostě jen zpracovává neobvykle velká data) a ta si naalokuje veškerou dostupnou paměť, takže systém jde do kytek, jak to podle něj mám řešit, to mám tu aplikaci přestat používat a odinstalovat, aby náhodou nedošlo na killer? nebo si mám napsat vlastního démona, který bude hlídat paměť a sestřelí, co jí žere kriticky mnoho, aby náhodou nedošlo na killer (neměla by to snad být jeho práce)?

Co takhle opravit tu aplikaci? Když jí OOM killer „zastřelí“, tak asi stejně nebude moc použitelná…

[Luboš Luňák]

A k cemu potom OOM killer je? Jestli "neni" problem, ze OOM killer by se spis mel jmenovat OOM mass murderer a nahodne postrili i uplne nevinne procesy, tak to uz stejne tak tam muzou dat random() a hotovo. Kazdy se obcas utne a je dost otrava, kdyz se kvuli tomu musi vsechno restartovat (napr. OOM killer se zeleznou pravidelnosti vybere jako prvni k zastreleni jeden z nejdulezitejsich procesu z KDE a vsechno jde do haje, museli jsme na to pridavat workaround).

[Filip Jirsák]

On snad někdo pravidelně používá programy, které sežerou veškerou dostupnou paměť? Může se to dít ppogramátorům nebo testerům – pak ale není problém v algoritmu OOM killeru, ale v tom, že nemá uživatel šanci říci mu, který přesně proces je ten, který OOM pravděpodobně způsobí. Pak by ale podle mne jediné řešení bylo umožnit uživateli nastavit procesu příznak, že v případě nedostatku paměti má být přednostně odstřelen tento proces.

[Michal Kubeček]

Nebo spíš obráceně: označit procesy, které smějí být odstřeleny jen v případě, že není jiného zbytí (třeba sshd).

[Filip Jirsák]

Ale to přece neodpovídá realitě. V praxi pokud někdo (opakovaně) pouští proces, který zabere veškerou paměť, ví přesně, který proces to je, a jeho představa je taková, že OOM killer zabije právě tenhle jeden proces.

Pokud někdo spustí nějaký proces „v dobré víře“ a ten proces užírá paměť postupně, je to stav prakticky nepopsatelný, tudíž nealgoritmizovatelný, a asi nemá smysl bádat nad tím, jestli by OOM killer neměl proces k ukončení vybírat nějak lépe. Protože jak posoudí uživatel, že OOM killer vybral pro zabití špatný proces? Jedině tak, že má dopředu představu, který proces měl vybrat místo něj. A jsme zpátky u toho, označit dopředu proces(y), u kterých předpokládám, že by mohly dělat neplechu.

[happy barney]

v praxi to funguje tak, že php zožerie pamäť, ale oom killer odstrelí databázu

[cronin]

To je nie chyba, to je predsa umela inteligencia: OOM Killer odvodil, ze PHP vyzralo pamat len kvoli tomu, ze z databazy natiahlo prilis vela udajov.

[Michal Kubeček]

Mně šlo spíš o to, aby když už dojde na nejhorší a OOM něco odstřelí, aby to nebyl zrovna ten jediný proces, který by mi umožnil s tím systémem na dálku něco udělat (i kdyby to měl být jen korektní restart).

[happy barney]

je to dôležité (sshd)? do inittabu s ním

[Filip Jirsák]

Bral jsem to, že když už mi na nějakém takhle důležitém systému běží nějaká leakující aplikace, je už to stejně skoro jedno, protože nějaký nekorektní restart je ten nejmenší z problémů, který mi to způsobí

Ale jinak je to pravda – pro běžný provoz by se hodilo, aby nad některými aplikacemi držel OOM ochranou ruku, pro testování je zase lepší, když mu některé hříšníky nabonzuju rovnou předem. A jak napsal někdo níž v diskuzi, obojí je možné. Teď už zbývá jenom doladit startovací skripty, aby při spuštění daemona nastavily procesu tu hodnotu podle nějakého rozšířeného atributu spouštěné binárky automaticky, a máme vystaráno

[happy barney]

oom_adj je tuším dedené, takže v rc skriptoch bude stačiť echo $oom_value > /proc/$$/oom_adj

[Luboš Luňák]

Ach jo, tady si to zase nekdo predstavuje jak Hurvinek valku :-/. To mam porad laborovat s nastavovanim nejakeho priznaku na proces, ktery by zrovna mozna nahodou mohl mit problem, jen protoze kernel neni schopny pochopit, ze ma killnout proces, ktery za posledni okamzik nejvic narostl? A ano, vim, ze dokonaly algoritmus pro OOM killer nejde, jenze soucasny k nemu ma asi tak daleko jako trabant k formuli - nakonec taky nejak dojede.

A hlavni problem soucasneho OOM killeru neni ten, ze by se obcas netrefil. On se napoprve netrefi skoro nikdy.

[Filip Jirsák]

jen protoze kernel neni schopny pochopit, ze ma killnout proces, ktery za posledni okamzik nejvic narostl

Nepovede tenhle postup k zabití poslední spuštěné aplikace, nebo k zabití X, pokud oním zlobivým procesem je nějaká GUI aplikace? Případně vybije všechno možné, ale trvale rostoucího bumbrlíčka nechá na pokoji?

[Stanislav Brabec]

Ono je těžké odhadnout, kdo je ten nebezpečný bumbrlíček.

Představte si proces, který náhodně, zhruba jednou za sekundu, naalokuje pár kilobajtů, a nikdy nic nevrátí. Přestože vypadá nenápadně, časem dokáže zlikvidovat systém.

Proti němu vypadá proces, který zrovna desetkrát alokoval paměť, aby zobrazil okno „Není dostatek paměti!“ jako hlavní podezřelý. Až postřílí podobně „podezřelé“ dostane to i ten bumbrlíček.

Je ovšem ještě šance, že ten po první chybě paměť žrát přestane, a jen bude sedět na tom, co už má. Pak už jde použít jedině heuristiku: „Odstřel toho, kdo má nejvíc.“ Je skoro jasné, že podle této heuristiky to jako první dostanou Evolution, Firefox a X.

[Filip Jirsák]

Právě proto tvrdím, že buď můžu jako uživatel předem označit aplikaci, která je „podezřelá“, nebo holt vybíjení procesů nebude moc daleko od náhodných výstřelů, protože spolehlivě určit viníka nelze. Ostatně která aplikace je viník je vždycky věc názoru člověka, který ty aplikace provozuje – obecně může mít nějaká aplikace dobrý důvod alokovat postupně čím dál víc paměti, stejně jako to může znamenat memory leak. A i aplikace, kde je to memory leak, může takhle leakovat „chtěně“ – např. když se programátor pokouší zjistit, kde je vlastně problém.

[petr_p]

/proc/PID/oom_adj:

This file can be used to adjust the score used to select which processes should be killed in an out-of-memory situation. Giving it a high score will increase the likelihood of this process being killed by the oom-killer. Valid values are in the range -16 to +15, plus the special value -17, which disables oom-killing altogether for this process.

[Ondrej 'SanTiago' Zajicek]

> to mám tu aplikaci přestat používat a odinstalovat, aby náhodou nedošlo na killer?

Co poustet takovou aplikaci s vhodne nastavenym ulimitem?

[kavol]

a to "vhodné nastavení" zjistím jak? - nemám křišťálovou kouli, abych v okamžik spuštění nějaké aplikace věděl, jestli druhý den sestřelí systém když bude zabírat 500 MB paměti nebo až když bude zabírat 1,5 GB ...

[trekker.dk]

když je chyba v aplikaci (nebo třeba ani ne chyba, prostě jen zpracovává neobvykle velká data) a ta si naalokuje veškerou dostupnou paměť, takže systém jde do kytek, jak to podle něj mám řešit, to mám tu aplikaci přestat používat a odinstalovat, aby náhodou nedošlo na killer?

Pokud aplikace zpracovává neobvykle velká data a dojde paměť, tak "je se systémem něco špatně", protože jsi tam nedal dost paměti. Je produktivnější to řešit (přidat paměť), protože jinak se situace pravděpodobně bude opakovat.

A ne, nemáš ji přestat používat, aby na killera náhodou nedošlo, ale máš potom zjistit, co se stalo a pokusit se tomu nějak předejít. OOM killer je jenom nouzový prostředek, který má napravovat chyby někoho jiného - mnohem efektivnější, než vylepšovat OOM killer, je podle mě věnovat čas na opravu těch chyb.

[kavol]

Pokud aplikace zpracovává neobvykle velká data a dojde paměť, tak "je se systémem něco špatně", protože jsi tam nedal dost paměti. Je produktivnější to řešit (přidat paměť), protože jinak se situace pravděpodobně bude opakovat.

jenomže dopředu to obvykle nevím - ano, až to zjistím, mohu paměť dokoupit, jenomže mezitím jaksi potřebuju něco, aby zasáhlo právě v ten okamžik, kdy problém nastane; můj počítač totiž jaksi nepodporuje hotswap pamětí, nehledě na to, že bych s ním třeba chtěl ještě něco udělat než do toho krámu pro tu paměť poběžím atd.

A ne, nemáš ji přestat používat, aby na killera náhodou nedošlo, ale máš potom zjistit, co se stalo a pokusit se tomu nějak předejít. OOM killer je jenom nouzový prostředek, který má napravovat chyby někoho jiného - mnohem efektivnější, než vylepšovat OOM killer, je podle mě věnovat čas na opravu těch chyb.

ta myšlenka nebyla tak úplně dokončená, měl jsem ještě říct, že takhle bych mohl odinstalovat celý systém

samozřejmě je lepší, aby k chybám nedocházelo, ale občas se holt stane, a říkat, že není vhodné snažit se, aby ten "nouzový prostředek" nebyl co nejefektivnější, je divné ... asi jako kdyby někdo říkal, že nepotřebujeme tolik přispívat na hasiče, aby měli co nejlepší vybavení, protože když někde začne hořet, mám pak zjistit, co se stalo, a pokusit se tomu předejít (nejspíš instalovat tabulku s nápisem "neodhazute nedopalky" a najmout hlídače na vynucení dodržování? )

[miso]

Nikdy nehas benzinem ohniste!

Ted je to uz jedno, ale pro priste

[geebranz]

More news

cryotherapypensacolafl.com