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.
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.
Swap mám vypnutý, je to přežitek z dob kdy ~bylo pod 2GB RAM
Ano, je to k z*sr*ání, když na linuxu dojde paměť, Na OS X stejně. Začnou se brutálně sekat., někdy se z toho nevylížou
Na windows se to chová jinak, tam to ukončí proces, někdy se až pozdě ukáže hláška, že systém má nedostatek paměti. A někdy spadne grafický driver (nebo něco jako crss.exe) a systém je ve vegetativní smrti. - beží- reaguje na capslock, ale nedá se s ním nic dělat.
Mé požadavky jsou:
Zakázat zabíjení procesů - lepší suspend - ukázat hlášku a něco udělat (třeba vyjímečně zapnout swap) - leda s vyjímkou CHILD procesů chromia
Již nějakou dobu je také k na5rání. Minimálně 10 let.