systemd 通过 .service 文件的 [Service] 段配置资源限制，如 MemoryMax=、CPUQuota=、TasksMax=、LimitNOFILE= 等，作用于服务及其子进程；需 cgroups v2 支持，配置后 reload 并 restart 生效，可用 systemd-cgtop 或 systemctl show 验证。
在 systemd 中，可以通过 unit 文件配置资源限制，防止服务过度占用系统资源（如 CPU、内存、文件描述符等）。这些限制直接作用于服务进程及其子进程，无需额外工具或内核参数调整。
常用资源限制参数
在 .service 文件的 [Service] 段中设置以下参数：
-
MemoryMax=：硬性内存上限（如
MemoryMax=512M），超出时触发 OOM killer 杀死该 cgroup 内进程 -
CPUQuota=：CPU 时间配额（如
CPUQuota=50%表示最多使用 0.5 个逻辑 CPU） -
TasksMax=：最大并发线程/进程数（如
TasksMax=200，防 fork 炸弹） -
LimitNOFILE=：打开文件数限制（如
LimitNOFILE=65536） - LimitNPROC=：用户级进程数限制（影响该服务能 fork 的子进程总数）
配置方式与生效步骤
以 myapp.service 为例：
- 编辑 unit 文件：
sudo systemctl edit --full myapp.service - 在 [Service] 下添加限制项，例如：
MemoryMax=1G CPUQuota=75% TasksMax=150 LimitNOFILE=32768
- 重载配置：
sudo systemctl daemon-reload - 重启服务：
sudo systemctl restart myapp - 验证是否生效：
systemctl show myapp.service -p MemoryMax -p CPUQuota或查看 cgroup：cat /sys/fs/cgroup/system.slice/myapp.service/memory.max
注意事项与常见问题
部分限制依赖内核特性（如 cgroups v2），需确认系统启用：
- 检查 cgroup 版本：
mount | grep cgroup，v2 应显示type cgroup2 -
MemoryMax 在 cgroups v1 中对应
MemoryLimit=（已废弃），v2 才推荐使用 - 若服务由 root 启动但降权运行（如
User=www-data），资源限制仍作用于整个 service cgroup，不受用户级 ulimit 影响 - 临时覆盖限制可用
systemctl set-property myapp.service MemoryMax=2G，重启后失效
调试与监控建议
观察资源实际使用有助于合理设限：
- 实时查看内存/CPU 使用：
systemd-cgtop - 查某服务当前内存用量：
systemd-cgls /system.slice/myapp.service+ 对应 cgroup 路径下的memory.current - 日志中留意 OOM 事件：
journalctl -u myapp --since "1 hour ago" | grep -i "killed process" - 避免设限过严导致服务异常，建议先监控基线再逐步收紧
