Názory k článku
Fedora 32 bude zřejmě mít EarlyOOM pro případy nedostatku paměti

Nevím, mně OOM killer nikdy nedělal svoji práci. Ani na Ubuntu, ani v Archu. Vždycky pomohl jen tty3 a ruční kill přes htop nebo rovnou tvrdé vypnutí PC

A co si představuješ pod tou "správnou prací oomzabijáka"?

(netrolím, jen by mne to doopravdy zajímalo...)

Za mě bych řekl, že zafunguje dřív, než si vyrvu zbytky vlasů při čekání, až systém bude reagovat nebo než to budu muset řešit manuálně já.

Záleží na rychlosti zabírání paměti. Jsou dva odlišné případy. Vysvětlím:

A) (typicky) více procesů, které vytěžují paměť běžně, třeba kombinace Firefoxu, u programátorů třeba nějakého IDE a běžícího kompileru, u grafiků třeba renderování 3D nebo i 2D grafiky, dále třeba kancelářských balíků, atd. Využití paměti narůstá (i díky postupnému spouštění procesů a podprocesů) tak nějak kontinuálně.

Zde by dle mého měl v případě přiblížení se ke 100 % OOM killer rozhodně něco udělat. Ideálně asi trochu aktivněji přeposílat do swapu, pokud by to nepomohlo, pak SIGTERM nejvíce vytěžujícího procesu, protože vybrat z nejvíce vytěžujících procesů nějaký konkrétní, třeba který zrovna není aktivní (okno/služba na pozadí), OOM killer asi úplně nezvládne. Problém je v poslední době z rozdělováním běhu do více procesů/podprocesů (proces pro každou záložku v prohlížeči, atd.), zde by asi musel OOM killer koukat i na nějakou prioritu, případně zkusit postupně s odstupama zavřít více procesů, dokud se využití paměti nesníží pod nějakou rozumnou hladinu (záleží i na velikosti paměti samozřejmě). V každém případě rozhodně lepší než žádat po uživateli, aby něco vypínal skrz tty3 ručně nebo nezkušeně dlouze podržel tlačítko pro vypnutí nebo zcela laicky tahal ze zásuvek a odbaterkovával všechno co má na pracovním stole.

B) (typicky jeden) proces, který v několika vteřinách způsobí navýšení z běžných 700 MB na 100 %. Dle mojí zkušenosti se často jedná třeba o bitcoin miner skripty v zlomyslných webových stránkách nebo bugy v balíčcích způsobující zacyklení.

Tenhle případ je zákeřný a myslím, že není jednoduché předejít zamrznutí celého Linuxu, nevadí mi, že OOM killer nezareaguje. Pokud by ale dokázal po očku sledovat, jak je paměť využita a dokázal i zareagovat, pokud míra využití paměti v několika vteřinách poskočí o řády a její růst neustává, mohl by se pokusit vší silou (SIGKILL) ukončit buď nejvíc vytěžující proces, nebo ideálně celý systém (shutdown). Pokud se jedná o uživatelem spuštěný proces, pak většinou stačí odhlášení uživatele, ale nelze na to spoléhat (u Windows dřív na nedostatek paměti fungovalo ruční odhlášení z Ctrl+Alt+Del obrazovky asi nejlíp).

7. 1. 2020, 22:21 editováno autorem komentáře

[hawran.diskuse]

Vis, podle me je v porve rade dulezite, aby takovy "zabijak procesu" byl schopny relativne presne urcit, ktery proces je odpovedny za zasek systemu a ve kterem zdroji ( vycerpava pamet, zbytecne zatezuje procesor ci nejaky jiny kriticky hw prostredek...) . Teoreticky to tak sice nevypada, ale podle mych zkusennosti neni vubec trivialni zalezitost. Pak je teprve mozno resit dalsi. Ve stavu dnesni doby si myslim, ze urceni zdivoceleho procesu je pomerne nespolihlive.

Taky by bylo fajn, kdybyu uzivatel (admin) byl schopen urcit procesy, do jejichz behu se killer nema vubec michat, nebo jej docasne deaktivovat. Nekdy je potreba spustit ulohu, ktera maximalne vytizi stroj (nad limity) a nechces aby se ti do toho michaly regulacni procesy v jadre.

OK.
Díky všem za odpovědi.

Již nějakou dobu se to diskutuje? Já si to jako téma vášnivých debat pamatuji už z bulletin boardu strahovských kolejí v roce 2000 ;-) Na počítačích s 16MB RAM to bylo docela pochopitelně aktuální téma, hned po debatě kolem toho, kam na disku správně umístit swap partition..

Neznám žádný OS, který by se v OOM situaci nezačal chovat divně. Linux defaultně overcommituje tak to je o něco víc vidět. Ale i windows se umí chovat srandovně. Třeba handler ctrl-c v cmd.exe v sobě má alokaci takže když je commit charge na limitu, tak se to na tom zasekne.

Ono chovani pri OOM je opravdu problematicke, oom killer v jadru taky pocita nejaka skore procesu a podle toho je zabiji. Takze jediny rozdil v earlyoom bude, ze bude to skore pocitat jinak, ale stejne zvlast na serveru to bude opravdu slozite (na desktopu vestinou oom killer zabije ten spravny firefox ze). Bohuzel systemd se svymi tty on demand (tedy ze pousti tty az po prepnuti na nej) do reseni oom vneslo novy rozmer, kdy uz se ani ten login neobjevi, takze ani reseni pres "tty3" nefunguje.

Nebojte se, brzy určitě vyjde systemd-oomd, a bude vše vyřešeno.

Jste si jistý, že jste tu pomlčku napsal na správném místě?

Řešení přes tty3 stále funguje, jen člověk musí počítat s tím, že už to nebude tak bleskurychlé, jako dřív

A zkusila jste si zapnout swap? Já si taky nějakou dobu myslel, že swap nepotřebuju, ale pak jsem zjistil, že s ním je to rychlejší.