OOM Killer behavior
Hi, for one reason or another I sometimes run out of RAM (e.g. memory leak or programming error) after which the system completely freezes and becomes really hard to recover (moving the cursor at 1px per minute). Seems like the OOM killer is not kicking in even though it should. I read that people use https://github.com/rfjakob/earlyoom to kill programs earlier. Anyone have experience with setting this up in bazzite? Or other ways to improve the OOM killer behavior? Like, I'd be fine with it just killing any program that uses more than 30 GB or something...
Solution:Jump to solution
I had a lot of lockup issues due to the OOM killer not kicking in fast enough. It typically does eventually kick in but I needed to patiently wait for up to 2 minutes for that to happen. earlyoom worked really well for me with a laptop that had 16GB of ram. In this case my machine was running Aurora-dx but the instructions below should work fine for Bazzite
You can install it by layering it with
```bash...
10 Replies
Solution
I had a lot of lockup issues due to the OOM killer not kicking in fast enough. It typically does eventually kick in but I needed to patiently wait for up to 2 minutes for that to happen. earlyoom worked really well for me with a laptop that had 16GB of ram. In this case my machine was running Aurora-dx but the instructions below should work fine for Bazzite
You can install it by layering it with
Reboot the machine.
This was the earlyoom config file I used (in /etc/default/earlyoom)
This is what these config settings that I used do:
* -r 60 = Print memory report every minute instead of every hour
* -m 8 = trigger at Available minimum memory 8%
* -s 8 = trigger at free minimum swap 8%
* -avoid = list of processes I wanted to stop earlyoom from terminating, in my case I don't want vscode and MS Teams from getting terminated. You might want to add steam to the list for your usecase as you really wouldn't want the steam process getting terminated
Now enable the earlyoom service with:
magic sysrq has an option to invoke oom killer manually
https://wiki.archlinux.org/title/Keyboard_shortcuts#Kernel_(SysRq)
to enable sysrq run
rpm-ostree kargs --append=sysrq_always_enabled=1Thanks! I'm kind of surprised bazzite (and/or other ublue distros) don't come with a pre-configured userspace OOM killer. It makes a lot of sense for a desktop-focused distribution to just kill a random high usage app instead of letting it lead to these hard to recover from slowdowns. I read up on this a little bit and it seems that e.g. Ubuntu does ship with one.
I wonder -- is it also possible to configure earlyoom or another method to just kill a program if it reaches a certain % of memory usage? I have 64 GB of RAM so I'm pretty confident a program is misbehaving when it's using e.g. 40 GB.
Edit: Nevermind, I guess earlyoom just kills the process with the most memory usage so that would result in the same behavior regardless
Thanks, the sysrq key is which key exactly? On the wikipedia page it's a dedicated key but I don't think I have that.
Not a fan of layering since they advice against that in the ublue docs but I'll try, thanks for the detailed answer @wolfyreload
@Woutuuur alt + sysrq + f
Scroll a bit down in the page I linked
Yes but what's the sysrq key
SysRq is printscreen on some keyboards
Alt + S on recent thinkpads I think?
I see, I'll try that if I'm ever in the situation again
Sysrq oom is responsive for me
Couple memory leaks in zed today where it would've been useful but now with earlyoom it should hopefully not really happen again
Works 👍
