5 ms·

I actually don't understand why systemd-oomd is needed given MemoryMax= ( https://man7.org/linux/man-pages/man5/systemd.resource-control.5.html https://man7.org

I actually don't understand why systemd-oomd is needed given MemoryMax= ( https://man7.org/linux/man-pages/man5/systemd.resource-control.5.html https://man7.org/linux/man-pages/man5/systemd.resource-contr... ). What are they doing differently?

danobi 6y ago
When a cgroup hits its memory.max the kernel OOM killer is invoked. systemd-oomd enables finer grained policy than the kernel OOM killer. systemd-oomd can also prevent livelocks (which memory.max does not).
geofft 6y ago
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 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).
- danobi 6y ago
  Yes, exactly. > It looks like systemd-oomd is related to (based on? from the same people as?) Facebook's oomd Yep, I authored the original standalone oomd (along with many others' help) and Anita has been working on systemd-oomd. There's plans to converge and simplify everything that's been learned from oomd into systemd-oomd so the community can benefit from all our experiments.

danobi 6y ago

When a cgroup hits its memory.max the kernel OOM killer is invoked. systemd-oomd enables finer grained policy than the kernel OOM killer. systemd-oomd can also prevent livelocks (which memory.max does not).

geofft 6y ago

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 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).

danobi 6y ago
Yes, exactly. > It looks like systemd-oomd is related to (based on? from the same people as?) Facebook's oomd Yep, I authored the original standalone oomd (along with many others' help) and Anita has been working on systemd-oomd. There's plans to converge and simplify everything that's been learned from oomd into systemd-oomd so the community can benefit from all our experiments.