systemd MemoryLow 与 MemoryMin 怎样影响内存回收保护

给 systemd 服务设置内存保护时，MemoryLow= 和 MemoryMin= 都不是“把内存预留出来”的简单开关。它们分别对应 cgroup v2 的 memory.low 和 memory.min：前者是可回收时的弱保护，后者是更强的最低保护。实际效果还要看父级 slice 是否有足够的保护额度，以及同级服务是否发生竞争。

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

如果服务只是希望在内存紧张时尽量晚一点被回收，优先考虑 MemoryLow=；如果服务必须获得一段最低保护，则使用 MemoryMin=，但要同步规划父级额度，避免过度承诺。

MemoryLow 和 MemoryMin 到底差在哪里

Linux 内核把这两类设置归入 memory controller 的 protection。回收发生时，系统会优先从未受保护或保护较弱的 cgroup 回收页面。

两者都接受字节数、带二进制单位的大小或相对物理内存的百分比。比如 MemoryLow=512M 表示 512 MiB，而不是十进制的 512 MB。infinity 可以表示继承父级提供的全部保护，但生产配置不应把它当成无限增加物理内存。

先用 drop-in 给目标服务配置保护

不要直接改发行版或软件包提供的 unit 文件。使用 drop-in 可以让配置独立存在，也更容易查看和撤销。下面以一个名为 worker.service 的服务为例：

# 创建只覆盖内存保护字段的 drop-in，避免改动软件包原始 unit
sudo systemctl edit worker.service

# 在打开的编辑器中写入以下配置；MemoryLow 是弱保护
[Service]
MemoryLow=512M

# 保存后让 systemd 重新读取 unit 文件，并重启服务使运行状态一致
sudo systemctl daemon-reload
sudo systemctl restart worker.service

# 快速查看 systemd 保存的属性，确认值来自目标服务
systemctl show worker.service -p MemoryLow -p MemoryMin -p ControlGroup

如果服务的内存使用具有更高优先级，可以把同一字段替换为 MemoryMin=512M。不要同时把两者写成相同的大值来“叠加保护”：它们不是两个独立的内存池，真正的保护效果仍受层级分配和可用内存约束。

父级额度会决定子服务能获得多少保护

systemd 的资源控制建立在 cgroup 树上。服务通常位于某个 slice 下，父级配置会向下分配，子级不能绕过父级限制。对于非根节点，官方文档建议在祖先节点配置对应的保护额度，再把额度明确分配给需要保护的子节点。

可以把配置拆成两层：父级负责划定一个可保护的范围，关键服务再在范围内获得自己的保护。示例使用自定义 slice：

# /etc/systemd/system/app.slice.d/memory.conf
# 父级先提供一个总的弱保护额度，子服务在其中竞争
[Slice]
MemoryLow=1G

# /etc/systemd/system/worker.service.d/memory.conf
# 关键 worker 在父级额度内获得最低保护
[Service]
Slice=app.slice
MemoryMin=512M

# /etc/systemd/system/cache.service.d/memory.conf
# 缓存使用较弱保护，压力大时允许它先被回收
[Service]
Slice=app.slice
MemoryLow=256M

上面的数值只是配置关系示例，不代表任何机器的推荐容量。如果 app.slice 的父级没有相应的保护空间，或者同级子服务的保护之和超过父级可提供的范围，实际效果会按内核的层级保护规则折算，不能把它理解成每个服务都获得一份独立的物理内存。

用三组信息检查配置是否落到正确的 cgroup

排查时先确认 unit 的控制组路径，再查看 systemd 的有效属性，最后读取对应 cgroup 的接口文件。下面的命令只读，不改变服务配置：

# 查看 unit 所在的 slice、控制组路径和两个保护值
systemctl show worker.service \
  -p Slice -p ControlGroup -p MemoryLow -p MemoryMin

# 用树形视图确认 worker.service 是否真的位于预期的 app.slice 下
systemd-cgls --all --unit worker.service

# 将 systemd 返回的 ControlGroup 路径拼到统一 cgroup 挂载点后读取接口
cg=$(systemctl show -p ControlGroup --value worker.service)
sudo sh -c "cat /sys/fs/cgroup${cg}/memory.low; cat /sys/fs/cgroup${cg}/memory.min"

# 查看服务内存事件，帮助区分保护不足与达到硬上限等不同问题
sudo sh -c "cat /sys/fs/cgroup${cg}/memory.events"

这里的 memory.low 与 memory.min 是内核视角的接口值；systemctl show 反映的是 systemd unit 属性。二者不一致时，先检查系统是否使用统一层级、服务是否重新加载，以及 ControlGroup 是否指向了预期路径。

什么时候选 MemoryLow，什么时候选 MemoryMin

优先选 MemoryLow 的情况：服务可以承受一定程度的回收，只是希望在压力下不要和普通工作负载同一优先级；典型例子是热缓存、构建缓存和非关键后台任务。它不会因为写入了配置就让该服务永远不被回收。

考虑 MemoryMin 的情况：服务在回收后会产生明显抖动，且你能为它明确划出最低内存预算。由于该保护更强，错误设置会把压力转移给其他 cgroup，甚至让系统更早进入 OOM 风险，所以要先确认父级额度和同级服务的合计需求。

不要用它们代替上限：如果目标是限制服务最多能用多少内存，应单独评估 MemoryHigh= 和 MemoryMax=。其中 MemoryHigh= 更偏向节流，MemoryMax= 是最后一道硬限制；保护字段和上限字段解决的是不同问题。

常见误区和一份配置清单

• 把 MemoryLow= 当成绝对保留量：它仍可能在没有其他可回收内存时被回收。
• 只改叶子服务，不规划父级 slice：保护是层级的，父级没有空间时子级不能凭空获得保证。
• 给所有服务都设置很大的 MemoryMin=：过度承诺会把回收压力集中到未保护工作负载。
• 只看 unit 文件，不看 ControlGroup：模板 unit、实例 unit 或自定义 slice 可能让你查错目录。
• 把保护与限额混为一谈：要控制峰值使用量，应该另外设计 MemoryHigh= 或 MemoryMax=。

落地前可以按下面顺序检查：目标服务是否属于预期 slice；父级是否有可分配的保护额度；关键服务与普通服务的保护强度是否有层次；配置 reload 后接口值是否变化；最后再结合 memory.events 和业务指标观察回收或 OOM 风险。

相关问题

MemoryLow 和 MemoryMin 可以同时设置吗？

可以分别配置，但通常应先明确最低保护和弱保护的职责，不要把两个字段都设置成很大的数值。实际效果要结合父级和同级分配判断。

MemoryLow 会阻止 OOM killer 吗？

不会。它只是让回收优先级更低，systemd 文档明确指出在没有其他可回收内存时仍可能回收，以避免触发 OOM。

为什么写了 MemoryMin 但服务看起来没有得到同样多的内存？

先检查父级保护、同级竞争和实际 cgroup 路径。保护值不是独立内存池，层级资源会按父子关系分配。

MemoryHigh 和 MemoryMin 应该怎么搭配？

MemoryMin 用于表达回收保护，MemoryHigh 用于在高使用量时施加节流。二者可以共同设计，但必须为服务的正常工作集、峰值和父级总预算分别留出空间。

参考资料

systemd 资源控制：https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html

Linux cgroup v2：https://docs.kernel.org/admin-guide/cgroup-v2.html