Dotaz: Příliš zuřivé swapování a zamrznutí systému

[Howard]

Omylem jsem otevřel 6 GB textový soubor v Kate, ten ho začal otvírat a během pár sekund se rozjel disk naplno, přestala se hýbat myš a hrát hudba.
Čekal jsem hodinu, dvě, ale nevzpamatovalo se to a musel jsem to resetnout.
Nešlo se připojit na SSH, SysRq+F nic nedělá, CTRL+ALT+F1 rovněž bez reakce.

OS: openSUSE 15.1 se všemi updaty
kernel: 4.12.14-lp151.28.36-default

Když tentýž pokus na stejném počítači udělám v Mintu 19.1 s kernelem 4.15, tak se Kate začne otvírat, rovněž vše zamrzne, ale po 2 minutách se to vzpamatuje, Kate zmizí a na konci výpisu dmesg je:

Out of memory: kill process 5757 (kate) score 945 or sacrifice child
Killed process 5757 (kate) total-vm:15752236kB, anon-rss:7567388kB, file-rss:0kB, shmem-rss:0kB

Swap v obou případech 16 GB jako oddíl na SSD disku.
RAM 8 GB

Mám s tímhle problém dlouhodobě na více PC a nejde jen o Kate, někdy stačí spustit další browser s několika záložkami (zatímco mám puštěný PhpStorm a Docker) a je zle. Někdy se mi podaří přes SSH po několika minutách killnout nějaký proces a vzpamatuje se to, ale spíš se to nepovede, někdy po půl hodině přestane daný počítač odpovídat na síti a nezbyde fakt nic jiného než reset.

Řešil jsem i nastavení swapiness, ale nijak mi to nepomohlo.

Funguje v openSUSE vůbec to OOM? Proč se to nikdy nevzpamatuje?
Dá se to nějak konfigurovat, nebo třeba porovnat s nastavením, které je v Mintu?
Nerad bych přecházel na jiné distro (ačkoliv pokud to nemá rozumné řešení, tak se tomu nebráním).

Odpovědi

[MadCatX]

Mrkni na earlyoom.

[Howard]

Diky, to jsem neznal. Zkousim to, ale vypada to, ze mi to problem nevyresi. Ono to vypada, ze se ten daemon vubec nedostane ke slovu.

[MadCatX]

To je divné, určitě ten daemon běží? Můžeš zkusit změnit konfiguraci, aby intervenoval ještě dřív, než je výchozích (myslím) 5 % volné RAM. Napadá mě, že kdyby systém zdechnul kvůli přílišném swapovaní a nikoliv kvůli plně obsazené paměti, earlyoom by tu asi nepomohl. Řešením by asi bylo swap prostě odstřelit nebo nějak ohnout earlyoom, aby začal fungovat při swapu zaplněném třeba z 50 %. Nemohl bys aspoň pokusně swap vypnout a sledovat, jak se to bude chovat?

[DaBler]

Zajímavé, to jsem neznal!

[lertimir]

Primárně je třeba se zamyslet nad 16GB swapu pro 8GB operační paměť. Proč? Suse prostě ten swap využilo. Mint evidentně nešel přes více než total_vm>2x_operační_pamět. Swap měl smysl v době 64-128MB operační paměti a rychlosti ATAPI-4(5) tedy 66-100MB/s (cca 2000). Nyní je 100x větší pamět ale jen 5x větší rychlost. Nyní nemá cenu řešit swap a bud ho nemít vůbec nebo jen minimální nebo po případě ho mít na hibernaci přesně ve velikost OP. Jakýkoliv takový problém řešit zvětšením paměti. Když snížíte swap suse to zařízne také a je vidět že takovýto swap nemá smysl.

[Michal]

Jakýkoliv takový problém řešit zvětšením paměti

A kdyz otevre omylem 1TB soubor, tak mu poradime at si poridi 2TB pameti?
Mozna jsem prilis staromodni ale otevrenim soboru by se nemelo dat dostat OS do kolen. Ale treba jsem jenom prilis staromodni.

[lertimir]

Pokud bude bez swapu tak to oom kiler vyřeší. hloupá konfigurace zdrojů dostane do kolen system ne otevření souboru.

[Michal]

Nikoliv. OS, ktery zacne trashovat tak straslivym zpusobem, ze zcela vyhladovi vsechny ostatni procesy (tak, ze se neda v radu minut pripojit na ssh) na ukor jednoho jedineho je spatne navrzeny. Sorry jako.

[MadCatX]

Problém je, že OOM killer zasáhne až v případě, kdy je paměti fakt kriticky málo. Ve spoustě případů ale systém efektivně zdechne daleko dříve, protože si kritické procesy začnou vzájemně vyhazovat data z cache. Případ, kdy systém zůstane mrtvý i několik hodin může IMHO nastat právě v situaci, kdy paměť úplně nedošla (a ani nedojde) ale na plynulý provoz systému už je jí málo.

Proto jsem výše linkoval earlyoom. Ten lze nastavit tak, aby začal nabobtnalé procesy čistit o chvíli dřív, než se systém začne kácet. Dál mu lze nastavit blacklist procesů, které zabít nesmí, i kdyby trakaře padaly - třeba Xorg.

[Howard]

Chapu. Ale koukam na dalsi svuj PC a tam mam 8 GB RAM a 8 GB swap. K problemum zacina dochazet, uz kdyz je vyuzito kolem 4 GB swapu. A hibernaci potrebuju, resp. rad bych, aby fungovala.

[Howard]

Nepomohlo mi ani zmensit swap na 2 GB. Chova se to porad stejne.

Je to nejake divne, sledoval jsem vypis z 'free', dokud jsem mohl, prakticky ubyvala pamet a ubyvala, a jakmile si to jenom sahlo na swap, okamzite to bylo zamrzly.

Tentokrat se mi ale povedlo, ze pri zatuhnuti bylo aktivni okno s terminalem, tak jsem vytukal 'killall kate' a za pul hodiny to zabralo

[Howard]

Ja jsem teda tedko na neco prisel.

Zapnul jsem SysRq - https://linuxconfig.org/how-to-enable-all-sysrq-functions-on-linux

A ted i kdyz je Suse mrtve, zmacknu ALT+SysRq+F a v tu chvili Kate zmizi, v dmesg je:

sysrq: SysRq : Manual OOM execution
Out of memory: Kill process 10413 (kate) score 610 or sacrifice child
Killed process 10413 (kate) total-vm:6965284kB, anon-rss:6180160kB, file-rss:2644kB, shmem-rss:0kB

Jeste budu delat pokusy, ale vypada to, ze by mi to takhle i stacilo.

[Howard]

Jeste pokus pri zapnutem 22 GB swapu (coz je nesmysl, ja vim, zmensim ho).

Tentokrat to trvalo dele, zrejme se musel swap vic zaplnit, nez si oom zacal "myslet", ze by mel neco sestrelovat.

Kazdopadne po 2 minutach obcasneho mackani ALT+SysRq+F...

[ 4122.302795] Out of memory: Kill process 10864 (kate) score 221 or sacrifice child
[ 4122.302812] Killed process 10864 (kate) total-vm:7746560kB, anon-rss:6958968kB, file-rss:1564kB, shmem-rss:0kB
[ 4122.533711] show_signal_msg: 39 callbacks suppressed
[ 4122.533714] GpuWatchdog[9817]: segfault at 0 ip 000055643f0fdbdd sp 00007f46618eb680 error 6 in vivaldi-bin[55643b104000+72c3000]
[ 4122.562542] oom_reaper: reaped process 10864 (kate), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

samo se to bohuzel nespusti :(

a jako bonus mi spadl i vivaldi...

Tak jako workaround mi to takhle staci.

[Max]

Řešením je omezit ram pro user space pomocí cgroups. Příklad:
How to Limit some User Memory Resources on CentOS/RHEL using cgroup
Zdar Max

[rastos]

ulimit sa už nenosí?

[Max]

To umí jen limit per process, což podle mně nic moc neřeší.
Zdar Max

[Josef Kufner]

Může to být taková hrubá základní ochrana proti procesům, které se utrhly ze řetězu. Třeba když něco najednou spořádá pár GB paměti. V případě Chrome to zabije jen ten jeden rozežraný tab. Pokud jsou problémy typicky způsobené jednotlivými procesy a nikoliv celkovým zahlcením systému, může to stačit a je to jednodušší nastavit.

[Max]

To samozřejmě nepopírám. Jde tak ošetřit spoustu věcí, ale na cgroups to prostě nemá, tam lze opravdu dělat komplexní ošetření.
Zdar Max

[Howard]

Dekuji vsem za prispevky, pomohly mi.

Ted jsem vyzkousel openSUSE 15.2 beta, ktere ma uz jadro 5.3.18, s 2 GB swap oddilem.
A vysledek?

[ 1019.829713] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=kate,pid=3708,uid=0
[ 1019.829722] Out of memory: Killed process 3708 (kate) total-vm:3219976kB, anon-rss:704880kB, file-rss:3080kB, shmem-rss:0kB
[ 1019.937939] oom_reaper: reaped process 3708 (kate), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

Takze nadhera! Nez to vyjde, tak uz to s navrzenymi resenimi na 15.1 nejak doklepu