Systemd Will Be Working To Improve Out-Of-Memory Linux Handling With Facebook OOMD

[phoronix]

Phoronix: Systemd Will Be Working To Improve Out-Of-Memory Linux Handling With Facebook OOMD

While more Linux distributions have begun packaging (and in the case of Fedora, potentially deploying by default) EarlyOOM as the out-of-memory monitoring daemon for trying to improve the Linux desktop's handling of low memory situations, systemd ultimately should be picking up its own out-of-memory daemon in the months ahead...

http://www.phoronix.com/scan.php?page=news_item&px=Systemd-Facebook-OOMD

[SomeByteiUsedToKnow]

So if Fedora implements their version first and then comes systemd update with its own modified FB version, which one of those versions will Fedora use in the end? Or I misunderstood and they will all integrate into one OOM solution later on?

[boxie]

So if Fedora implements their version first and then comes systemd update with its own modified FB version, which one of those versions will Fedora use in the end? Or I misunderstood and they will all integrate into one OOM solution later on?

I guess that is a question the steering committee would need to answer based on the merits of both solutions.

I hope the eventual solution that makes it into systemd has a step 1 of "please release any memory you don't need" message to applications.

[geearf]

So if Fedora implements their version first and then comes systemd update with its own modified FB version, which one of those versions will Fedora use in the end? Or I misunderstood and they will all integrate into one OOM solution later on?

They're not definitive on this yet it seems, but the logical option would be to use earlyoom now, and replace by something better when it comes.
Lennart said half to a year, so that's still quite some time before making it to a distro.

[jntesteves]

So if Fedora implements their version first and then comes systemd update with its own modified FB version, which one of those versions will Fedora use in the end? Or I misunderstood and they will all integrate into one OOM solution later on?

Whatever works best at a given time will be made the default. Defaults can and do chance all the time. For next Fedora version that'll probably be EarlyOOM.

[King InuYasha]

There is a Fedora COPR repository available too that offers OOMD should you not want to build it from source.

Actually, oomd is packaged in all stable versions of Fedora, so you don't even need the COPR repo.

[JPFSanders]

Excellent, I'm really glad that this issue is finally getting some attention, truth is that any solution even if it is just an intermediate one is better than the current status quo.

There have been plenty of times last year where I had to pull the cable on my then 12GiB workstation, now 16GiB due to the OOM not being able to kill the memory hogs in my system (Firefox, Chromium and Skype) quick enough to get out of the IO starvation cycle of constant swap trashing.

Whatever the solution I hope there is a clear way to indicate to the system what processes are excluded from the early OOM, I do not want my VMs to die unexpectedly because Chromium is eating RAM and a KVM process is using the largest amount at the same time.

[Shiba]

This obviously needs to be fixed

[timofonic]

Why not more developers collaborate to make this happen earlier and not be done only by Facebook developers?

This situation needs to be solved ASAP, it sucks that constant problems related to not reliable OOM killing are happening to everyone.

[CommunityMember]

Actually, oomd is packaged in all stable versions of Fedora, so you don't even need the COPR repo.

The issue is that the current available oomd rpm is not really good enough for all cases (oomd was developed primarily for the server space with a fairly well defined use pattern, and while that is a very important use case, most of the complaints in Fedora is about the workstation space, which has a very different use pattern). FB has an improved version of oomd which they are working on (more configurable, better defaults for workstation type loads), which is the work in progress. When that is considered ready (or at least good enough), it is intended it will get rolled up, and integration with systemd will happen.

Earlyoom works (for some use cases) today. If you want to make the decision today to deploy something, that is probably the choice to make. But if you can wait more towards the latter part of the year, systemd-oomd should be better choice. Maybe.