大约 3 年来,我一直在 cgroupv1 中使用它来自动对为不同 vhost 提供 Web 请求服务时产生的子进程进行分类apache2-mpm-itk
,它一直运行良好,当某个 vhost 开始占用过多的 CPU/RAM 时,oom killer 会处理该特定的 vhost,而不会管其他的。cgrulesengd
apache2-mpm-itk
我现在正在准备一个新的 Debian 11 服务器,我发现我现在需要使用 cgroup v2。所以我试图将我的资源控制解决方案带入新世界。
当我使用该用户的资源控制创建我的例如时/etc/systemd/system/user-UID.slice.d/override.conf
,它们不适用于分叉进程,正如cgrulesengd
我用 确认的那样systemd-cgls
。相反,父级及其所有子级仍然属于同一个 apache2.service 切片。
有没有办法自动对与 systemd 生成进程不同的 cgroup 中的进程的子进程进行分类?
答案1
我在邮件列表中发布了这个问题systemd-devel
:
https://lists.freedesktop.org/archives/systemd-devel/2022-January/047257.html
以下是本杰明·伯格的回应:
https://lists.freedesktop.org/archives/systemd-devel/2022-January/047260.html
本杰明的回答非常有帮助。以下是两段摘录:
systemd will not help you with managing the cgroup sub-hierarchy
underneath the daemon. I suppose the most generic solution would be
something like cgrulesengd for cgroup v2. No idea if something like
that exists.
和:
Managing the cgroup hierarchy is quite simple in principle (mkdir and
then a write to cgroup.procs). Or, even better by using
CLONE_INTO_CGROUP when creating the processes. It is not that hard to
write small daemon that does this.
编辑:
看来 cgconfigparser 和 cgrulesengd 已更新以支持 cgroupv2。
在撰写本文时,它们必须从源代码构建。
该软件包可以从那里下载:
https://github.com/libcgroup/libcgroup/releases/tag/v2.0
然后按照步骤操作,例如:
./configure
make
cgconfig.conf 中的控制器参数名称可能不同,请确保在新世界中使用 cgroupv2 参数名称。