Systemd 247 Merges Systemd-OOMD For Improving Low-Memory/Out-Of-Memory Handling

[phoronix]

Phoronix: Systemd 247 Merges Systemd-OOMD For Improving Low-Memory/Out-Of-Memory Handling

Merged just minutes ago into systemd Git is the new systemd-oomd component pushed along by Facebook...

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

[geearf]

How well does this compare to the alternatives like earlyoom and nohang?

[zbyszek]

How well does this compare to the alternatives like earlyoom and nohang?

earlyoom is different approach: it monitors the *global* resource limits and then kills a single process when that resource usage hits a limit. It reuses kernel's oom_score that is also used by the built-in oom killer.

oomd is based on PSI, i.e. it monitors resource *pressure* using live information provided by the kernel, and instructs systemd to kill specific groups when that pressure it too high. So it allows configuring per-unit thresholds. It integrates closely with PID1. In particular configuration of thresholds is done in systemd units, and not in a separate config.

nohang is somewhere in between. If uses global PSI information (afaik, I might be wrong on this), but doesn't have per-unit limits or close systemd integration. It is also written in python... Python is a great language but not for a low-level tool like this.

[Raka555]

Python is a great language but not for a low-level tool like this.

Amen, brother ...

[timofonic]

earlyoom is different approach: it monitors the *global* resource limits and then kills a single process when that resource usage hits a limit. It reuses kernel's oom_score that is also used by the built-in oom killer.

oomd is based on PSI, i.e. it monitors resource *pressure* using live information provided by the kernel, and instructs systemd to kill specific groups when that pressure it too high. So it allows configuring per-unit thresholds. It integrates closely with PID1. In particular configuration of thresholds is done in systemd units, and not in a separate config.

nohang is somewhere in between. If uses global PSI information (afaik, I might be wrong on this), but doesn't have per-unit limits or close systemd integration. It is also written in python... Python is a great language but not for a low-level tool like this.

So....

What approach is better then?

[zbyszek]

What approach is better then?

oomd is more powerful and flexible than nohang which is more powerful and flexible than earlyoom. But more flexible also means that some configuration is required. So once everything has stabilized and we have done more testing, the experience with oomd should be better: quicker response but with a low chance of killing the wrong thing. But before that happens, the simpler approaches are probably going to be better. The version in systemd-247 is a preview: don't deploy it to your server farm just yet.

[polarathene]

What approach is better then?

It'd seem that systemd-oomd would be the better choice in time, especially for desktop users as DEs and packages embrace cgroups/slices more.

I believe Gnome and Plasma are pursuing better usage of cgroups to manage all their related processes and apps managed under their umbrellas. I don't follow Gnome development much, but with Plasma AFAIK that's still not quite there with 5.20, there was a blog post from one of the well known developers regarding future intentions/benefits with embracing cgroups and how that'd better help with KSysGuard (System Monitor) UI/management.

Along with that, from what I understand packages that already install with systemd unit configs just need to update with sane defaults if useful, otherwise as a user you might add your own for specific software that benefits you to make that extra effort.

[Space Heater]

oomd is more powerful and flexible than nohang which is more powerful and flexible than earlyoom. But more flexible also means that some configuration is required. So once everything has stabilized and we have done more testing, the experience with oomd should be better: quicker response but with a low chance of killing the wrong thing. But before that happens, the simpler approaches are probably going to be better. The version in systemd-247 is a preview: don't deploy it to your server farm just yet.

Since it appears that oomd kills an entire cgroup, what's the strategy for systemd/distros regarding cgroup granularity? Is it planned to have most applications be in their own cgroup? I'd imagine users wouldn't want oomd to kill all applications in the user slice cgroup if only one (say the browser) is the culprit.

[hakavlad]

oomd is more powerful and flexible than nohang which is more powerful and flexible than earlyoom. But more flexible also means that some configuration is required. So once everything has stabilized and we have done more testing, the experience with oomd should be better: quicker response but with a low chance of killing the wrong thing. But before that happens, the simpler approaches are probably going to be better. The version in systemd-247 is a preview: don't deploy it to your server farm just yet.

1. oomd cannot kill separate processes. If you will use oomd with xfce, mate, lxde - it will kill all the session. oomd cannot separately kill you browser tabs.

2. oomd cannot send low memory warnings.

3. nohang works well with any DE. nohang supports GUI notifications.

4. nohang supports PSI.

nohang is best solution for desktop right now.

[FLHerne]

Since it appears that oomd kills an entire cgroup, what's the strategy for systemd/distros regarding cgroup granularity? Is it planned to have most applications be in their own cgroup? I'd imagine users wouldn't want oomd to kill all applications in the user slice cgroup if only one (say the browser) is the culprit.

Yes -- and KDE does that today (as of Plasma 5.19); I believe recent GNOME versions do too.

David Edmundson wrote a good blog post about it: http://blog.davidedmundson.co.uk/blo...n-the-desktop/