systemd 资源隔离：服务级限额写法

发布时间:2025-12-24 12:38

## 概念 cgroup 的手工建组方式适合临时任务，长期运行的服务有更顺手的通道：systemd 天然为每个服务维护一个控制组，unit 文件里写几行资源指令，限额跟着服务的启停自动创建与销毁，不需要自己维护脚本。这是服务级资源管理的第一选择，学会了它，多数场景不需要直接碰 cgroup 文件系统。 ## 原理 systemd 启动服务时自动为它创建控制组，进程及其全部子进程都落在这个组里，资源指令翻译成对应控制组的上限参数。服务停止时组随之销毁，不会残留。这套机制与手工 cgroup 的关系是同一底座的两种入口，unit 指令是声明式的持久入口，手工建组是临时入口，前者省心后者灵活。改完 unit 文件执行 daemon-reload 加重启服务生效，运行中的服务也可以用 systemctl set-property 在线调整，不用中断业务。 ## 最小实操 ``` [Service] MemoryMax=2G CPUQuota=100% MemoryHigh=1536M ``` MemoryMax 是硬顶，触线即触发终止；MemoryHigh 是软线，越过软线后内核优先回收该组的内存，服务变慢但不会被杀，两道线配合，软线兜日常、硬线兜极端。CPUQuota 写百分之一百表示最多用一个核。改配置后验证。 ``` systemctl daemon-reload systemctl restart myapp cat /sys/fs/cgroup/system.slice/myapp.service/memory.max ``` ## 常见错误 一是只设硬顶不设软线，服务在触顶瞬间被杀，连告警的机会都没有；二是限额拍脑袋，没有先观测服务日常的资源曲线，把正常峰值也圈在了线外，表现为服务周期性变慢；三是忘了限额是组级别的，服务拉起子进程也一并计入，外部脚本被服务调用时同样占这个组的额度，重叠任务容易误触上限。排查这类误触有个固定入口：控制组目录里的内存事件文件记录了触发次数，次数持续增长就是额度设小了。顺云云服务器上部署多组服务时，给每个服务的 unit 配上这两道内存线，配合控制台的监控告警看曲线，机器的整体稳定性会有肉眼可见的提升。