Linux systemd.slice 怎样给同组服务设置资源父级

我在把几组后台 worker 放到同一台 Linux 主机时，最容易踩的坑不是单个 .service 文件怎么限流，而是多个服务各自配置后，资源边界难以统一。更稳妥的做法是创建一个自定义 systemd.slice，再让同组服务通过 Slice= 挂到这个父级。这样 CPU、内存和任务数可以在一处管理，子服务仍然保持独立启停。

官方地址：https://www.freedesktop.org/software/systemd/man/latest/systemd.slice.html

systemd.slice 先解决的是服务分组

systemd 把 slice 视为一棵资源管理树中的节点。根节点是 -.slice，常见服务默认位于 system.slice；自定义的 batch.slice 可以作为多个 worker 的共同父级。slice 名称中的短横线还表达层级，例如 batch-worker.slice 会落在 batch.slice 下面。

这和 target 的“启动编排”不是一回事。slice 主要回答“这组进程属于哪棵资源子树”，服务的启动、停止和依赖关系仍由各自的 unit 配置负责。

先创建一个明确的资源父级

把自定义单元放到 /etc/systemd/system/batch.slice，只在 [Slice] 中写这组服务的共同约束。下面的数值只是演示配置，生产环境应根据主机容量和服务特征调整。

# /etc/systemd/system/batch.slice
[Unit]
Description=后台批处理服务的共同资源父级

[Slice]
# 限制整棵子树最多使用一个 CPU 核心的 40% 时间。
CPUQuota=40%
# 内存压力较大时优先回收这棵子树的内存，避免直接把它当硬上限。
MemoryHigh=2G
# 统计并限制该 slice 及其子单元可创建的任务数。
TasksMax=256

CPUQuota= 是上限；MemoryHigh= 更接近节流水位，超过后进程可能被强烈减速；TasksMax= 控制任务数量。若必须设置最后一道内存防线，可以另行评估 MemoryMax=，但它触发 OOM 的代价更高，不应因为“统一配置”就随意使用。

让每个服务指向同一个父级

不要直接修改发行版在 /usr/lib/systemd/system 下提供的原始 unit。对已有服务使用 drop-in，既能保留软件包升级内容，也能只覆盖资源归属：

# /etc/systemd/system/worker-a.service.d/10-batch-slice.conf
[Service]
# 把 worker-a.service 放进统一的 batch.slice 资源子树。
Slice=batch.slice

对 worker-b.service 等同组服务建立同样的 drop-in。Slice= 应写在 [Service] 段，而资源参数写在 slice 的 [Slice] 段；混写位置会让配置意图变得不清楚，也容易把单服务限制误当成父级限制。

# 让 systemd 重新读取新增的 slice 和 drop-in 配置。
sudo systemctl daemon-reload

# 先启动资源父级，再重启需要迁移的服务。
sudo systemctl start batch.slice
sudo systemctl restart worker-a.service worker-b.service

# 读取服务声明的父级；输出应包含 batch.slice。
systemctl show worker-a.service -p Slice

父级资源设置会沿子树继承

slice 的价值在于把“共同上限”集中到父级。父级设置会约束其中的服务和更深层的子 slice；某个服务可以再写更严格的 CPUQuota= 或 MemoryMax=，但不能把父级的总边界扩大。换句话说，父级适合控制一组服务的总预算，子级适合表达单个服务的额外收紧。

用 unit 信息确认归属和有效参数

不要只看 drop-in 文件是否存在，真正有用的是检查 systemd 当前加载的 unit 信息。下面的命令分别确认服务的 Slice、父级的 cgroup 路径和几个资源字段：

# 检查两个服务当前绑定到哪个 slice。
systemctl show worker-a.service worker-b.service -p Id -p Slice

# 查看父级的 cgroup 路径和资源控制字段。
systemctl show batch.slice \
  -p ControlGroup \
  -p CPUQuotaPerSecUSec \
  -p MemoryHigh \
  -p TasksMax

# 按 cgroup 树查看 batch.slice 下的服务层级。
systemd-cgls --unit batch.slice

如果服务仍然显示在 system.slice，先检查 drop-in 的文件名和段落位置，再确认是否执行过 daemon-reload，最后重启服务让进程进入新的 cgroup。父级字段显示为默认值，也不一定代表 slice 没有加载：还要结合 unit 的实际 cgroup 路径和当前 systemd 版本支持的属性判断。

修改失败时怎样回滚

回滚的关键是先解除服务与自定义父级的绑定，再删除不再需要的父级资源配置。不要一上来删除 slice 文件后期待运行中的服务自动回到旧位置；运行中的进程归属要通过服务重启完成调整。

# 删除或移走对应的 drop-in 后，重新加载 unit 定义。
sudo systemctl daemon-reload

# 重启服务，让它回到默认的 system.slice 或新的 Slice=设置。
sudo systemctl restart worker-a.service worker-b.service

# 确认回滚后的服务归属，再决定是否删除空的 batch.slice 文件。
systemctl show worker-a.service -p Slice

如果只是想临时放宽资源，不必重写服务文件；可以先调整 batch.slice 的参数并 reload，再观察服务是否恢复。正式环境还应把 slice 文件和 drop-in 纳入配置管理，避免手工回滚后下次部署又被覆盖。

这套做法适合哪些服务

当一组服务共享业务目标、需要共同限额、又不希望合并成一个大进程时，自定义 slice 很合适，例如批处理 worker、定时导入任务或同一租户的一组后台服务。若服务之间需要完全独立的资源预算，或者需要按请求动态创建大量实例，就应该进一步设计子 slice 或 transient unit，而不是把所有限制都堆在一个父级上。

我的经验是先只设置一项最能解释问题的父级约束，例如任务数或 CPU 配额，确认归属稳定后再增加内存策略。这样出问题时，能分清是服务本身、父级继承还是主机总体压力，而不是面对一串同时生效的参数。

常见问题

把服务写进同一个 slice 后，它们会共享一份内存吗？

不会。slice 提供的是共同的 cgroup 资源边界，不会把多个服务的地址空间合并成一份内存。父级设置表达的是整组服务的预算或上限。

Slice= 和 Wants= 有什么区别？

Slice= 描述服务属于哪棵资源层级；Wants= 描述启动时希望拉起哪些 unit。一个负责分组，一个负责依赖，不应互相替代。

为什么改了 batch.slice 但服务行为没变化？

先确认服务的 Slice 是否已经指向它，再检查是否 reload 并重启服务。还要注意父级 slice 或主机 cgroup 层级可能存在更严格的上限，子服务不能突破祖先限制。

相关官方资料：https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html、https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html