On Mon, Dec 28, 2020 at 7:30 PM Davide Cavalca via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, 2020-12-28 at 16:22 -0800, Kevin Fenzi wrote: > > 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. > > This is correct. For server usecases, I can see services primarily > getting started via systemd or via a container manager. In both cases, > every service should get its own cgroup by default. Usecases I can see > as being problematic: > - stuff like runit would probably put all their charges under the same > cgroup > - all cronjobs will be under the cron cgroup (systemd timers would work > just fine though) > - if one starts a long running service in an unortodox way (say, using > screen), that's likely going to end up accounted as part of their user > sessions > > All in all, I think this should be a fairly safe change for servers, as > long as we document properly the potential pitfalls. > Indeed. In fact, I would suggest this probably would encourage people to move to the current best practice of separating contexts for each thing they are running, which is probably a good thing. > > 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. > > Depending on the web server, this shouldn't be too difficult to do > (either by leveraging template services in systemd, or by writing some > glue logic that leverages the run API to setup slices directly). > It's generally been good practice to have individual systemd service units for WSGI applications being run through harnesses like gunicorn or uwsgi. For example, when pagure is deployed using nginx, the main web app and the docs web app are both separate systemd services invoking gunicorn. Thus, they get their own resource controls through their own cgroups. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
