nohang VS oomd

For desktop use, nohang does what the name says.

https://github.com/hakavlad/nohang

Personally I thought https://github.com/hakavlad/nohang worked pretty well, and it'll also notify the user if it's about to start killing things, but I haven't bothered to install it in fedora. I did tweak the systemd-oomd config to be less aggressive though.

SOLUTION: After struggling with this nightmarish unpredictable kernel panic for two weeks, I confirmed nohang is capable of stopping this problem for real.

посмотри https://github.com/hakavlad/nohang/issues/122

I'm trying to install this app called " nohang" for memory problems. https://github.com/hakavlad/nohang i wasn't sure which type zorin is based on.

Thanks. Looking into this as well. Further digging in this sub over the past couple days have brought up earlyoom as well as https://github.com/hakavlad/nohang as interesting things to pursue.

Sounds like the complaints indicated on nohang's repo. I also have low memory. nohang and zram make mine work better than macs/wins with higher memory.

OOMKiller has a bunch of issues. Its heuristics don't apply well across the wide range of workloads Linux provides (webserver? Database server? build server? desktop client? Gaming machine?), each of which would require its own tuning. (random example: https://lwn.net/Articles/761118/)

That's why some orgs implemented their own solutions to avoid OOMKiller having to enter the picture, like Facebook's user-space oomd: https://github.com/facebookincubator/oomd

I use paru to install/update the softwares on my laptop. I usually update the system twice per week. But recently I've noticed that oomd-git package was showing in the AUR updates everytime I ran the paru command. So, I checked the upstream URL but the main branch shows no new commits since last month. I have no idea why is this happening and weather it's a paru issue or oomd-git issue.

Additionally, you might want to check this: https://github.com/facebookincubator/oomd

I think the distinction is that MemoryMax= is just an interface to the cgroupv2 setting, i.e., that rule is implemented inside the kernel and invokes the kernel's OOM killer within a cgroup. The manpage for systemd-oomd says, "systemd-oomd is a system service that uses cgroups-v2 and pressure stall information (PSI) to monitor and take action on processes before an OOM occurs in kernel space."

It looks like systemd-oomd is related to (based on? from the same people as?) Facebook's oomd https://github.com/facebookincubator/oomd , whose documentation gives a bunch of reasons as to why you would prefer a userspace oomd that takes in PSI data and can be configured to proactively kill misbehaving processes instead of just letting the kernel OOM killer handle it. The major reason is time to recovery: a misbehaving process can cause a system to be so far under pressure that the kernel OOM killer will take a long time to flush things out, but a userspace component can respond in advance with more configurable rules (and more flexibility, since the kernel doesn't believe you're at capacity yet).

oomd - developed by facebook and will be default in Fedora 34, it is part of Systemd 247 but still in experimental stage