Proč mi zabiják OOM zabil Chromium

[mikesznovu]

Na linuxu radi zabijak OOM, zabil mi browsera. Jde nejak nastavit, aby ten hajzl nerusil moje kruhy?
systemd invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
Out of memory: Killed process 13104 (chromium-browse) total-vm:724616kB, anon-rss:220904kB, file-rss:0kB, shmem-rss:3408kB, UID:1000 pgtables:750kB oom_score_adj:300


K tomu se poji divna vec. mel jsem otevren chromium asi 20 taby. pohoda. Nekolik hodin, pak jsem uspal pocitac,..... celou dobu jsem mel zapnuty htop a koukam na vyuziti na nic nenasvedcovalo, nejakemu pruseru.
....

 po pul dni probudil .., pokracoval v operacich  v chromu, ale spis taby zaviral. Asi 20 minut.  Je mi divne ze spotreba pameti nenapadne roste, swap je na maximu. Ale po kazdem zavreni se o neco, 10MB uvolni, RAMka taky pomalu.  Zapnu devtools na jedne strance, neco am chci postelovat, po 2 minutach zamrzne mys. Zkousim Ctrl+W jestli se to hne, ale po dalsi minute vidim, ze se mi zavrela okna (pomalu,ne najednou) a dokonce se odhlasuju. Po prepnuti do Ctrl1 vidim, ze je to v hajzlu, ramka skoro prazndna, opravdu jsem byl odhlaseny.

Da se zjistit, jestli ten hajzl zabil rovnou chromium-browse nejvyssiho ?  Tomu neni nic svaty? Proc treba nezabil render proces chromu nebo subframe,  gpu process? to by nezavrelo chrom, ale jen killnulo taby( zadne smajliky s vypichnutymi oci na ouskach tabu jsem nevidel). Pripoustim, parent proces chromu mohl mit nejvetsi podil RAM.

Jenze = = htop , serazeno dle MEM , nejvetsi sloupec bylo chrome a mel 9.4%. (nevim z ceho se to pocita a ostatni sloupce neumim cist)

je ten nebezpecny xindl oom nejak laditelny, aby nejak procesy  mel zakonem zakazano prznit? Pokud ano, do takove granularity, ze se rozlisi hlavni parent proces chromium  a render subproces (rozdil je v cmdline urcite)?

[Reklama]

[Zopper]

No, Chrome bude právě ta aplikace, co žere nejvíc paměti a vypadá, jako by nejvíc mohla leakovat. Takže bude mít asi nejvyšší oom_score.
https://askubuntu.com/questions/60672/how-do-i-use-oom-score-adj

[Vít Šesták (v6ak)]

V dmesg nebo journalctl by mělo jít vidět, co všechno OOM killer sejmul.

Nemusel to nutně být kernelový OOM, jsou tu i různé user-space killery (systemd-oomd, earlyoom, oomd, …), které ale mohou logovat jinam. Nicméně nejspíš to bude vidět v journalctl pod rootem.

Swap máte? Z popisu chování hádám, že spíše ne.

[CPU]

Chrom se dá vrátit do stavu před uzavřením, tj. znovu otevřít taby klávesovou zkratkou, pokud se tedy neobnoví rovnou sám.

[mikesznovu]

Log jsem si schoval  . Vše se stalo v jedné sekundě(myslím časová razítka vstřiku do journalu). Swap mám (1800MB na na zram zařízení), RAM 2048MB.

Ten hajzl se jmenuje
systemd invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0,
oom_score_adj=0
oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=init.scope,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/user@1000.service/app.slice/dbus.service,
task=chromium-browse,pid=13104,uid=1000
Out of memory: Killed process 13104 (chromium-browse) total-vm:724616kB,
anon-rss:220904kB, file-rss:0kB, shmem-rss:3408kB, UID:1000 pgtables:750kB oom_score_adj:300
Bluetooth: BNEP (Ethernet Emulation) ver 1.3

kompletnější výpis, kde je spousta adres a čísel

Kód: [Vybrat]

systemd invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
CPU: 1 PID: 1 Comm: systemd Not tainted 5.4.210-327 #1
Hardware name: plesnivychleba
[<c011112c>] (unwind_backtrace) from [<c010d4bc>] (show_stack+0x10/0x14)
[<c010d4bc>] (show_stack) from [<c0a54240>] (dump_stack+0x8c/0xa0)
[<c0a54240>] (dump_stack) from [<c0a4cd34>] (dump_header+0x54/0x1f0)
[<c0a4cd34>] (dump_header) from [<c026832c>] (oom_kill_process+0x1b0/0x1bc)
[<c026832c>] (oom_kill_process) from [<c0268fec>] (out_of_memory+0x110/0x380)
[<c0268fec>] (out_of_memory) from [<c02b3e44>] (__alloc_pages_nodemask+0x1118/0x133c)
[<c02b3e44>] (__alloc_pages_nodemask) from [<c02638a0>] (pagecache_get_page+0x170/0x388)
[<c02638a0>] (pagecache_get_page) from [<c0264170>] (filemap_fault+0x6b8/0x864)
[<c0264170>] (filemap_fault) from [<c03a83f0>] (ext4_filemap_fault+0x28/0x3c)
[<c03a83f0>] (ext4_filemap_fault) from [<c0298c1c>] (__do_fault+0x38/0x128)
[<c0298c1c>] (__do_fault) from [<c029d5a4>] (handle_mm_fault+0x85c/0xc18)
[<c029d5a4>] (handle_mm_fault) from [<c0115798>] (do_page_fault+0x114/0x388)
[<c0115798>] (do_page_fault) from [<c0115c78>] (do_PrefetchAbort+0x38/0x8c)
[<c0115c78>] (do_PrefetchAbort) from [<c0102148>] (ret_from_exception+0x0/0x18)
Exception stack(0xee8f5fb0 to 0xee8f5ff8)
5fa0:                                     00000000 ffffffe0 bec4687c 00000000
5fc0: 00000000 00000803 008039a0 00000024 00000000 b6f33b64 ffffffff 00000024
5fe0: 00000000 bec46638 b6dfb737 b6d597d8 400f0010 ffffffff
Mem-Info:
active_anon:92009 inactive_anon:92768 isolated_anon:0
                            active_file:64 inactive_file:0 isolated_file:0
                            unevictable:8 dirty:0 writeback:0 unstable:0
                            slab_reclaimable:11728 slab_unreclaimable:31006
                            mapped:11823 shmem:3162 pagetables:10596 bounce:0
                            free:10951 free_pcp:436 free_cma:0
Node 0 active_anon:368036kB inactive_anon:371072kB active_file:256kB inactive_file:0kB unevictable:32kB isolated(anon):0kB isolated(file):0kB mapped:47292kB dirty:0kB writeback:0kB shmem:12648kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
Normal free:43460kB min:3436kB low:4292kB high:5148kB active_anon:132492kB inactive_anon:123124kB active_file:196kB inactive_file:0kB unevictable:0kB writepending:0kB present:786432kB managed:750980kB mlocked:0kB kernel_stack:7264kB pagetables:10768kB bounce:0kB free_pcp:988kB local_pcp:328kB free_cma:0kB
lowmem_reserve[]: 0 10064 10064
HighMem free:344kB min:512kB low:2008kB high:3504kB active_anon:235544kB inactive_anon:247948kB active_file:4kB inactive_file:0kB unevictable:32kB writepending:0kB present:1288192kB managed:1288192kB mlocked:32kB kernel_stack:0kB pagetables:31616kB bounce:0kB free_pcp:756kB local_pcp:248kB free_cma:0kB
lowmem_reserve[]: 0 0 0
Normal: 375*4kB (UE) 213*8kB (UE) 192*16kB (UME) 96*32kB (UE) 27*64kB (UE) 17*128kB (UE) 30*256kB (UM) 44*512kB (UM) 0*1024kB 0*2048kB 0*4096kB = 43460kB
HighMem: 0*4kB 1*8kB (M) 7*16kB (U) 5*32kB (U) 1*64kB (U) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 344kB
5381 total pagecache pages
2138 pages in swap cache
Swap cache stats: add 1687612, delete 1685462, find 155928/1203175
Free swap  = 0kB
Total swap = 1455076kB
518656 pages RAM
322048 pages HighMem/MovableOnly
8863 pages reserved
32768 pages cma reserved

...
oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=init.scope,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/user@1000.service/app.slice/dbus.service,task=chromium-browse,pid=13104,uid=1000
Out of memory: Killed process 13104 (chromium-browse) total-vm:724616kB, anon-rss:220904kB, file-rss:0kB, shmem-rss:3408kB, UID:1000 pgtables:750kB oom_score_adj:300
[    273]     0   273    11145      178    32768      152          -250 systemd-journal
[    329]     0   329     5531       95    22528      303         -1000 systemd-udevd
...
[   4437]     0  4437     1309        3    10240      160             0 bash
[   5119]  1000  5119   128568     3219   503808    16958           300 chromium-browse
[   5219]  1000  5219   124614     1485   552960    11665           300 chromium-browse
[   5482]  1000  5482   156855    97994   458752    15354           200 chromium-browse
[   5878]  1000  5878   116172      482   432128     8064           300 chromium-browse
...
[  14760]  1000 14760   125086    13638   559104     1695           300 chromium-browse
[  14875]     0 14875     1267       50    10240       32             0 cron   
oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=init.scope,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/user@1000.service/app.slice/dbus.service,task=chromium-browse,pid=13104,uid=1000
Out of memory: Killed process 13104 (chromium-browse) total-vm:724616kB, anon-rss:220904kB, file-rss:0kB, shmem-rss:3408kB, UID:1000 pgtables:750kB oom_score_adj:300
   

[Reklama]

[Vít Šesták (v6ak)]

Kolik máte vm.swappiness (cat /proc/sys/vm/swappiness)? Pokud nula, tak to zhruba znamená, že se swapuje, když už to fakt jinak nejde. Což jednak není vždy ideální prioritizace (někdy je lepší něco odklidit do swapu, aby bylo místo pro cache, kam spadá i kód běžících programů), jednak v kombinaci se swapem v ZRAM mi to přijde celkem vražedné – aby šlo do ZRAM něco odswapovat, je potřeba volná RAM, což je při vm.swappiness=0 poněkud hlava 22. Zásek a případně OOM kill (protože swap s volným místem sice existuje, ale nedaří se do něj zapsat) je v takovém případě celkem očekávatelný výsledek.

EDIT: A BTW, 2G RAM je dnes docela málo.

[mikesznovu]

Mám defaultni hodnoty , systém sem neladil.takze swap je začátku skoro nulový, ale začne se těch 1.4GB časem plnit částečně a swap ma třeba pulkua ranka 1200, později. Třeba u 25 tabu, , ramka (podle htop grafu) má z 2000 plných třeba 1309 až 1700, ......až když swap je plný na doraz pozoruji ty problemy ty vraždy

Plnou rámků vidím méně často.

On ten zram je předvídatelný, má ratio 3ku1 až 2ku1.

(Nad 30 tabu se těch 3.8GB už nebezpečnè zaplňuje. Do 15 tabu je to ok)

Ta tam je tam napevno, s tím nic neudělám...
Je nějaký tip jak umravnit chromium nějakými flags , aby i při 50 oknech je nějak usnul na disk (tedy i mimo swap) :::pomalejší resumé jednotlivých tabu mi nevadí, ale musí být s kontextem, tedy aby se nereloadnul odnova, ale
aby měl Zpèt, Schroll pozici a text v formularich

[Vít Šesták (v6ak)]

Defaultní hodnoty – to mi moc neřekne, když nevím, o jakou jde distribuci. A i kdybych věděl, asi to nechci dohledávat a doufat, že najdu aktuální informaci.

OK, pokud je plný swap, tak problém asi nebude ve swappiness.

ZRAM je problém v některých konfiguracích. Může mít sebelepší kompresní poměr, ale reálně jsem viděl situace, kdy chyběla RAM, kernel se snažil swapovat, ale nemohl  zapisovat, protože chyběla RAM. Nakonec to systém po záseku nějak vyřešil (možná OOM kill). Ale v takové situaci na kompresním poměru moc nesejde.

Ad 3.8 GiB – ono to nejde moc sčítat, když je swap v RAM…

Usnutí na disk – od toho je právě swap. Je možné mít druhý swap, který bude na disku (/ SSD / microSD / …) a bude mít menší prioritu. Nečekal bych od toho ale zázraky a pochybuju, že by kernel uměl nějak rozumně automaticky přelít obsah z ZRAM swapu do druhého swapu. A pokud tím úložištěm bude flashové úložiště bez rozumného wear levelingu, nečekal bych dlouhou životnost. Zejména u microSD může být problém. Možná u A1 a lepších bude rozumný controller (ale ani to bych nebral na 100 %), možná u průmyslových to bude lepší.

[Jan Fikar]

2GB RAM je na Chrome málo a ještě ji užírá swap v zram. To bych zrušil a udělal pořádný swap (4GB?) na nějakým SSD.  Pokud chcete, tak jde ten swap taky komprimovat:

echo 1 > /sys/module/zswap/parameters/enabled
echo 1 > /sys/module/zswap/parameters/same_filled_pages_enabled
echo zstd > /sys/module/zswap/parameters/compressor
echo z3fold > /sys/module/zswap/parameters/zpool

Celkem pomáhá zapnout LRU_GEN, jestli je jádro alespoň 6.1:

echo y > /sys/kernel/mm/lru_gen/enabled

[anonacct]

2GB RAM?

Prosím tě, udělej něco pro ostatní a upgraduj. Ten čas cos spálil ostatním už teď je dražší než cena toho upgrade. Vždyť lidi vyhazujou i lepši sestavy do šrotu...

[mikesznovu]

sčítat swap ležící v RAM

Máš pravdu, spočítal jsem to blbě neodečetl jsem vlastní režii swapu jak https://player.ceskatelevize.cz/?sidp=11698534957&IDEC=218512120250001 v čase 5:45 a 4:35

/sys/module/ /sys/kernel/mm/lru_gen/enabled[/pre]

To momentálně v této verzi 5.4 jádra nemám... Možná po upgradu.