I've kind of thrown my hands up and accepted overcommit + uspace oomd; I test with WebKit too for my job which allocates 80-90G virt.
Is there a benefit to going without overcommit? I'm not a kernel hacker by any means, so I just kind of accept the knob and move on. /shrug
Conversation
Replying to
so, those allocations fail, and generally they can fail safe. but if you have a tab process go nuts, it will die instead of killing your system.
1
Replying to
Ah - I've been using systemd-oomd (Fedora 34 defaults) - it triggers on PSI and targets the app causing the stalls (IIRC also avoids targeting shell) - I can successfully report no more shell/X kills and no freezes for months!
Overengineered? probably. Seems to work though. 😅
1
Replying to
disabling overcommit disables the OOM killer. the memory hog will crash on its own if it doesn't handle malloc() returning NULL correctly.
1
so what you want to do is monitor for PSI stalls, and add additional swap as needed. but if a given process is hogging ram, stop adding swap just for that process.
1
Replying to
got it - I've just seen enough "clever" use of overcommit - for example, mmap'ing 32G of PROT_NONE memory between heaps to avoid heap overruns from succeeding in JSCore - phakeobj.netlify.app/posts/gigacage/, or using CoW+fork to save in Redis - redis.io/topics/faq#bac that...
3
Replying to
as far as I know, PROT_NONE mappings do not count against the commit charge. i also do not see how redis's CoW+fork is affected by overcommit
1
Replying to
FAQ says with overcommit off, if you have a 3G dataset and 2G free mem, then fork() fails since w/o overcommit Linux tries to guarantee that the child can write to every page, and there's isn't enough free mem for it. w/ overcommit, Linux promises away mem that's never used
1
Replying to
yeah, my advice for that situation is: don't run a production service under memory pressure
1
Replying to
<50% free mem on a Redis box isn't mem pressure unless you rewrite your entire db in the time it takes to save to disk; which I haven't seen on prod
running against the barrier is a major cost save as long as you can supply the needed disk IOPS
2
1
Full overcommit makes it work but so does reserving a ton of swap space without overcommit enabled. The swap space isn't intended to be used but it makes memory accounting happy and now you have a fallback when resource exhaustion happens. Your processes don't start being killed.
Even with full overcommit, the Linux kernel can handle memory pressure much better if you have swap. It can be zram instead of real swap. If you don't have any, it has to start purging actively used files including your executables/libraries rather than idle / unused dirty pages.