On Mon, Dec 28, 2020 at 07:44:04PM -0000, Tom Seewald wrote:
> On Tue, Dec 22, 2020 at 6:17 PM Anita Zhang
<anitazha(a)fedoraproject.org> wrote:
>
>
> Another variation on this theme: enable by default in Fedora 34 Server
> edition. And more broadly rolled out for Fedora 35.
>
> If it's broadly ready for Fedora 34, great. Otherwise, it seems like a
> good fit for Fedora Server edition, given sd-oomd's server origin and
> oomd2 been used in production for a number of years. It'd be a
> significant headline feature for Server edition, especially fitting
> for the in-progress reboot of that project. Any thoughts from Server
> WG folks?
I don't think enabling systemd-oomd for Fedora server by default makes a lot of sense
right now. Why would we want to automatically enable systemd-oomd in cases where users
either have to manually manage cgroups or risk a worse experience than what currently
exists with earlyoom? If a user is already creating/managing cgroups themselves, then
manually enabling systemd-oomd would be a minor extra step. But if the user isn't
managing cgroups (which I believe is the common case), then that user would be pretty
surprised if systemd-oomd wipes out a huge swath of running programs that happen to be in
the same cgroup.
With Gnome and KDE Plasma most of the cgroup creation is done automatically, so it makes
more sense to enable systemd-oomd by default as those systems are already set up for
systemd-oomd to work well.
I'm a bit unclear on this and perhaps the change owners could comment:
This operates on slices right? So in a server context each service is in
it's own slice. So, while it might kill say a httpd slice, other
services would be fine? That doesn't seem great if you are running
a deadicated webserver, but perhaps not so bad if you are running a
bunch of different services.
Also, perhaps there's some way to teach the web server applications to
put say different wsgi applications in different slices, but no idea if
any work has gone into that.
kevin