Hlavní navigace

Vlákno názorů ke zprávičce Fedora 32 bude zřejmě mít EarlyOOM pro případy nedostatku paměti od aleskva - Nevím, mně OOM killer nikdy nedělal svoji práci....

  • Aktualita je stará, nové názory již nelze přidávat.
  • 6. 1. 2020 18:54

    aleskva

    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

  • 6. 1. 2020 21:51

    hawran.diskuse

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

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

  • 7. 1. 2020 9:18

    Ink

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

  • 7. 1. 2020 22:17

    aleskva

    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

  • 8. 1. 2020 10:57

    D.A.Tiger

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

  • 9. 1. 2020 13:45

    hawran.diskuse

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