oomd
earlyoom
oomd | earlyoom | |
---|---|---|
5 | 61 | |
1,809 | 2,959 | |
0.5% | - | |
7.8 | 8.0 | |
20 days ago | 11 days ago | |
C++ | C | |
GNU General Public License v3.0 only | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
oomd
-
Defrag Like It's 1993
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
-
Paru is building oomd-git package from AUR everytime I run the update command.
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.
-
Holy memory usage, Batman!
Additionally, you might want to check this: https://github.com/facebookincubator/oomd
-
Systemd 248 RC3: systemd-oomd is now considered fully supported
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).
-
Arch runs out of memory, then crashes
oomd - developed by facebook and will be default in Fedora 34, it is part of Systemd 247 but still in experimental stage
earlyoom
-
Building a faster, smarter, Chromebook experience with the best of Google
EarlyOOM [1] could help with that quite a lot. Not to sure about using it on chromebooks, but linux got quite a bit more usable because of it.
[1] https://github.com/rfjakob/earlyoom
- Earlyoom – Early OOM Daemon for Linux
- Fedora Workstation 39
-
earlyoom VS thrash-protect - a user suggested alternative
2 projects | 12 Oct 2023
-
Linuxatemyram.com
> The system is not supposed to 'lock up' when you run out of physical RAM. If it does, something is wrong. It might become slower as pages are flushed to disk but it shouldn't be terrible unless you are really constrained and thrashing. If the Kernel still can't allocate memory, you should expect the OOMKiller to start removing processes. It should not just 'lock up'. Something is wrong.
I don't why but locking up is my usual experience for Desktop Linux for many years and distros, and I remember seeing at least one article explaining why. The only real solution is calling the OOMKiller early either with a daemon or SysRq.
> It should not take minutes. Should happen really quickly once thresholds are reached and allocations are attempted. What is probably happening is that the system has not run out of memory just yet but it is very close and is busy thrashing the swap. If this is happening frequently you may need to adjust your settings (vm.overcommit, vm.admin_reserve_kbytes, etc). Or even deploy something like EarlyOOM (https://github.com/rfjakob/earlyoom). Or you might just need more RAM, honestly.
Yeah. Exactly. But as the thread says, why aren't those things set up automatically?
- OOM still a disaster zone
-
Fedora spins
It's not that simple: some defaults may differ, and some features may arrive at different times (if ever). For example, earlyoom has been enabled on Workstation since F32, but the KDE Plasma spin got it one release later.
-
So what exactly do I do if Linux crashes?
Most answers will answer your question, but you can do better and avoid the freezes in the first place. IME almost every time the system froze up and didn't come back in a few seconds it was out of memory. The obvious solution is to add memory, but you can use Early OOM to kill hungry processes if you're running out of memory instead.
- Why is there no reliable way to receive signal when OOM killer decides to kill you
-
What do you do when Linux becomes unresponsive (in a frozen state,mouse clicks or keyboard doesn't work)
It sounds like you're running out of memory though, so if your OS's OOM killer isn't working as well as it should, you can try earlyoom as an alternative.
What are some alternatives?
nohang - A sophisticated low memory handler for Linux
le9-patch - [PATCH] mm: Protect the working set under memory pressure to prevent thrashing, avoid high latency and prevent livelock in near-OOM conditions
systemd - The systemd System and Service Manager
darling - Darwin/macOS emulation layer for Linux
XMousePasteBlock - Userspace tool to disable middle mouse button paste in Xorg
ZenStates-Linux - Dynamically edit AMD Ryzen processor P-States
latent-diffusion - High-Resolution Image Synthesis with Latent Diffusion Models
linux - Linux kernel source tree
picom - A lightweight compositor for X11 with animation support