broken software is going to do broken stuff. alpine ships with overcommit disabled, and life is good here.
Conversation
Replying to
so I went digging on my desktop session.. pretty much anything written in Go or anything with a JS engine attached to it (firefox, chromium, node) have like 10-100x VIRT compared to what's actually in use.
was considering disabling overcommit to try... doesn't look fun x.x
read image description
ALT
1
Do most applications even change their behavior with overcommit disabled or do they just malloc malloc malloc and end up crashing fast?
1
Replying to
sometimes i have tabs crash in my browser, but that's fine because it means my system isn't clogged up with bullshit
1
Replying to
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
1
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
That's not usage of overcommit. Fresh anonymous PROT_NONE / PROT_READ mappings aren't accountable memory. Normal file mappings aren't accountable memory either. Not using overcommit doesn't mean not being able to use huge amounts of VM. It limits accountable mappings, not others.


