Jak zabránit zahlcení systému vyčerpáním RAM

[mikesznovu]

Opět se mi na linuxu stalo, že mi jedna userspace (skript)aplikace spotřebovala celkovou dostupnou paměť 1024MB (bežně 200MB spotřeba). A ne, není to  pracovní mašina, ale jednoúčelový minipočítač, kde i 640MB musí stačit každému.účelu I když nevím jak je to možné, z 300MB textového souboru jsem chtěl najít pozici stringu, místo toho jsem asi omylem metodou fd.find.toarray nějak způsobil  rozkouskování textu na řádky a převod na pole a snahu to vypsat do REPL. Ale rozhasilo to celý systém, včetně  procesů pod rootem jako sshd,

Stroj reagoval na ping, chvíli ještě fungovalo DNS. Pak už ne. To samé ssh, chvíli se ukázal banner, pak už jen hluchý soket. stejně tak, wireguard spojení taky ještě chvíli šlo.
Překvapivě za 10 minut panikaření pomohlo čapnout monitor, klávesnici a  mačkat Alt, F2, killall node, ani ne naslepo, reagovalo to obstojně a taky jsem se živě podíval do okna zase jednou.. Mimojiné jsem zjistil, že došlo místo na disku na systémové partition microSDkarty, , lokalizoval jsem ho do stejného umístění jako daný 300MB soubor.

JMENOVAL  o jako on a měl příponu SAVE. ale velikost cca poloviční, víc se nevešlo na partition. Tak jsem ho smazal. Předtím jsem zjistil, že nejvíc cpu žral proces "editor ....soubor.txt.save" (což je nějaký jen alias pro zvolený nano,vim,neolbgtmacs, neonevim)

Je nějak možné v linuxu nastavit, aby proces nevyžral celou RAM? on sice pak nějak zafungoval oom a měl jsem v dmesg podpis vraha, že zabil.

Nedám dohromady už časovou souslednost, kdy došlo k spuštění skriptu, kdy zaplnění místa, kdy k zaplnění ram, kdy řádil OOM.




co se vůbec dělo? Mám pocit , že hw měl na krajíčku, podle mmc_Rescan

Kód: [Vybrat]

INFO: task kworker/2:0:12812 blocked for more than 122 seconds.
[  +0,000014]       Tainted: G        WC        5.10.63-v7+ #1496
[  +0,000007] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  +0,000008] task:kworker/2:0     state:D stack:    0 pid:12812 ppid:     2 flags:0x00000000
[  +0,000029] Workqueue: events_freezable mmc_rescan
[  +0,000012] Backtrace:
[  +0,000023] [<809f9df0>] (__schedule) from [<809fa7c8>] (schedule+0x68/0xe4)
[  +0,000012]  r10:81ea9800 r9:ffffe000 r8:00000000 r7:00000000 r6:40000113 r5:8f3eae80
[  +0,000007]  r4:ffffe000
[  +0,000013] [<809fa760>] (schedule) from [<80806328>] (__mmc_claim_host+0xe0/0x238)
[  +0,000009]  r5:81ea9a18 r4:00000002
[  +0,000012] [<80806248>] (__mmc_claim_host) from [<808064b8>] (mmc_get_card+0x38/0x3c)
[  +0,000011]  r10:00000000 r9:00000000 r8:00000080 r7:b776bd00 r6:81ea9a18 r5:00000000
[  +0,000008]  r4:81eaa800
[  +0,000012] [<80806480>] (mmc_get_card) from [<80810144>] (mmc_sd_detect+0x24/0x7c)
[  +0,000008]  r5:81ea9800 r4:81ea9800

[  +0,000014] Workqueue: kblockd blk_mq_run_work_fn
[  +0,000007] Backtrace:
[  +0,000016] [<809f0cb0>] (dump_backtrace) from [<809f1040>] (show_stack+0x20/0x24)
[  +0,000008]  r7:ffffffff r6:00000000 r5:60000193 r4:80fe5e54
[  +0,000010] [<809f1020>] (show_stack) from [<809f5250>] (dump_stack+0xcc/0xf8)
[  +0,000011] [<809f5184>] (dump_stack) from [<80303898>] (warn_alloc+0xd4/0x164)
[  +0,000009]  r10:00040800 r9:80f05008 r8:ffffe000 r7:80d18638 r6:00000000 r5:00000000
[  +0,000005]  r4:80f05008 r3:9a21c83e
[  +0,000008] [<803037c4>] (warn_alloc) from [<803049e8>] (__alloc_pages_nodemask+0x10c0/0x1184)
[  +0,000006]  r3:00000000 r2:80d18638
[  +0,000007]  r8:00000000 r7:00000000 r6:00000008 r5:00000001 r4:00000800


nějaký memy nfo

Kód: [Vybrat]

Mem-Info:
[  +0,000016] active_anon:9913 inactive_anon:178904 isolated_anon:0
               active_file:52 inactive_file:916 isolated_file:0
               unevictable:4 dirty:0 writeback:0
               slab_reclaimable:4508 slab_unreclaimable:7646
               mapped:7567 shmem:23022 pagetables:2289 bounce:0
               free:4547 free_pcp:0 free_cma:640
[  +0,000013] Node 0 active_anon:39652kB inactive_anon:715616kB active_file:208kB inactive_file:3664kB unevictable:16kB isolated(anon):0kB isolated(file):0kB mapped:30268kB dirty:0kB writeback:0kB92088kB writeback_tmp:0kB kernel_stack:2528kB all_unreclaimable? yes
[  +0,000016] DMA free:18188kB min:16384kB low:20480kB high:24576kB reserved_highatomic:0KB active_anon:39652kB inactive_anon:715616kB active_file:248kB inactive_file:3696kB unevictable:16kB write:0kB present:917504kB managed:892204kB mlocked:16kB pagetables:9156kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:2560kB
po zabití

Kód: [Vybrat]

[  +0,000009] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=node,pid=14707,uid=1000
[  +0,000064] Out of memory: Killed process 14707 (node) total-vm:494324kB, anon-rss:471572kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:486kB oom_score_adj:0
[  +0,082600] oom_reaper: reaped process 14707 (node), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

jde nějak v linuxu nastavit, aby nebylo možné  zahltit všechnu RAM? whitelistem si myslím, že by to byl zdlouhavý přístup (služeb běží dost) a blacklist zase nezamíří na předem neznámé scénáře-procesy (dneska node, zítra julia)

[Reklama]

[alex6bbc]

cgroups

[RDa]

Stroj s 1GB RAM neni vhodny na veci, ktere delate. Anebo pouzivate nevhodny SW

Bezne pracuji s nekolit set GB soubory - a bud si je nactu rucne do ram, nebo je mam v tmpfs.. a pokud se to tam nevejde, tak holt se to streamuje po kouscich.

Tenhle proces je potreba mit pod kontrou, a nepouzivat totalne nevhodne knihovny. Napr. rozdelit soubor na bloky jde A) jak pri cteni (nactu kousek, zpracuji, a tak dokola), anebo hipstersky - B) nactu to cely, rozdelim na casti a zpracuji po castech.

Je evidentni ze autori reseni B netusi jak pocitac funguje a meli by delat neco jineho, nez se venovat IT.


Reseni pro vas: - nastavit OOM aby byl sviznejsi, klidne tak, ze kdyz proces vyzere 90% volneho prostoru, tak at je ukoncen. Normalne se to totiz pousti az kdyz je potreba - na hranici 100%, kdy vsechno ostatni bylo uswapovano, zkomprimovano, uvolneno atd.. vlastne to je asi ta nejvetsi nevyhoda OOM - ze musi pockat az opravdu dojde pamet - a kdyz zrusite napr. diskovou cache, protoze ta potrebna jaksi neni.. tak vsechno bude neskutecne dlouho trvat.

[Tomas-T]

Povedlo se mi minulý týden skoro zahltit paměť serveru u zákazníka pouštěním vcelku jednoduché command line utilitky načítající z jedné strany miliony záznamů v CSV a ukládající je do DB přes EF. V testu se pracovalo jen s malými vzorky dat, takže to nebylo vidět.
Přesto, že jsem zapsané věci po zapsání do DB poctivě uvolňoval, bylo po pár hodinách běhu programu zabráno 10 GB RAM, protože EF si držel reference na už uvolněné objekty a GC to odmítal smazat.
Vyřešilo to až zahození celého EF kontextu po každém bulk insertu do DB a vytvoření nového před dalším zápisem, najednou zabraná paměť nepřekračuje 60 MB, což je odpovídající.
Člověk se stále učí. 

[_Tomáš_]

pravidelně spouštíme s memory bombou, představa, že mi uživatelský proces zbortí produkční server se mi prostě nelíbí, to by se stávat nemělo nikdy.

Ideálně z toho udělat systemd službičku a nastavit paměť, pokud se ti to nechce dělat, tak quick&dirty řešení je si spustit screen a v něm příkaz

systemd-run --scope -p MemoryMax=250M -p MemoryHigh=200M bash

který ti vytvoří shell s omezením paměti na 250MB, počítá se celkově za všechny spuštěné procesy v tomto shellu. Nevýhoda je, že k tomu potřebuješ být root.

[Reklama]

[mikesznovu]

Stroj s 1GB RAM neni vhodny na veci, ktere delate.

On to byl šlendrián srozumitelnost terminilogie api.
Tak schválně, co podle vás dělá metoda find na descriptoru/objektu otevř. souboru?

[jose1711]

man ulimit

[ondrah]

Stroj s 1GB RAM neni vhodny na veci, ktere delate.

On to byl šlendrián srozumitelnost terminilogie api.
Tak schválně, co podle vás dělá metoda find na descriptoru/objektu otevř. souboru?

Já bych si tipnul, že dělá to, co je o ní napsáno v dokumentaci, kterou jsem si samozřejmě přečetl.