Linux如何用cgroup限制进程资源

本文深入解析了Linux中使用cgroup v2精准、可靠地限制进程CPU和内存资源的现代实践，强调v1已淘汰、v2才是当前主流发行版（如Ubuntu 22.04+、Fedora 31+）的默认且推荐方案；文章直击关键痛点——不是“能否限制”，而是“是否限得准、防得住绕过”，详解如何通过systemd-run启动受控进程、正确配置CPUQuota与MemoryMax、规避memory.max非硬杀限的常见误解，并强调必须配合memory.swap.max=0才能实现严格的物理内存上限；同时澄清无法事后限制已有进程、手动操作cgroup目录的风险，以及为nginx等后台服务配置持久化资源限制的正确姿势，辅以实操命令、典型陷阱和深度诊断建议，助你真正掌控资源边界而非徒有其表。

怎么用 cgroup v2 限制一个进程的 CPU 和内存

Linux 下真正可控、现代的方式是 cgroup v2，v1 已逐步弃用，很多新发行版（如 Ubuntu 22.04+、Fedora 31+）默认启用 v2。关键不是“能不能限”，而是“限得准不准、会不会被绕过”。

实操建议：

• 确认系统用的是 v2：mount | grep cgroup，输出含 cgroup2 且挂载点为 /sys/fs/cgroup 才对
• 不要手动写 cgroup.procs —— 它只接受 PID，且写入后进程会立即加入，但子进程**不会自动继承**；更可靠的是用 systemd-run 启动带资源限制的临时服务
• 限制单个已有进程？不行。cgroup 管的是“进程组”，必须从启动时就约束。常见错误是想把已运行的 python3 train.py 塞进某个 cgroup，结果发现它立刻 fork 出的子进程全跑出去了

示例：启动一个最多用 50% CPU、1GB 内存的 Python 进程：

systemd-run --scope -p CPUQuota=50% -p MemoryMax=1G python3 train.py

为什么 memory.max 设了却没生效

cgroup v2 的内存限制靠 memory.max 控制，但它不是“硬上限触发即杀”，而是在内核尝试分配新内存页时检查——这意味着：进程可能已经占了 900MB，你设 memory.max = 1G，它还能继续 malloc 成功；但一旦突破 1G，后续分配就会失败（返回 NULL），或触发 OOM killer 杀掉该 cgroup 内最“重”的进程。

容易踩的坑：

• memory.max 值不能是 0 或 max，否则等于没限；设为 1G 要写成 1073741824 或 1G（单位支持 K/M/G，但注意大小写）
• 如果进程用了 mmap(MAP_ANONYMOUS) 或大页（hugetlb），这些内存可能不计入 memory.current，导致看起来“没超限却触发 OOM”
• memory.swap.max 默认是 max，意味着允许交换——如果你真想“物理内存严格≤1G”，还得显式设 memory.swap.max = 0

systemd-run 和手建 cgroup 目录的区别在哪

用 mkdir /sys/fs/cgroup/myapp 手动建目录也能限资源，但 systemd-run 是封装好的安全路径：它自动处理控制器启用、子树委派（delegation）、进程迁移边界和清理逻辑。

直接操作 sysfs 的风险：

• 忘记写 cgroup.subtree_control，比如想限 CPU 就得先往里面 echo +cpu +cpuacct，否则 cpu.max 文件压根不会出现
• 进程退出后目录不会自动删，残留的 cgroup 可能积累并占用内核资源（尤其在容器场景下）
• 普通用户默认无权写 /sys/fs/cgroup，而 systemd-run --scope 可通过 polkit 策略授权，无需 root

所以除非你在写容器运行时，否则别碰裸 sysfs 操作。

限制后台服务（比如 nginx）的资源要注意什么

systemd 服务天然属于 cgroup，但默认没开资源限制。关键是改服务单元文件，而不是临时 run 一个 scope。

实操要点：

• 编辑服务配置：sudo systemctl edit nginx.service，然后加：

[Service]
MemoryMax=512M
CPUQuota=30%

• 重启服务才生效：sudo systemctl daemon-reload && sudo systemctl restart nginx
• 注意：如果 nginx 配置了 worker_processes auto，它会按 CPU 核数起 worker，而 CPUQuota 是整体配额，不是每 worker 的份额——所以实际并发能力可能比预期低
• 验证是否生效：systemctl show nginx.service -p CPUUsageNS 或查 /sys/fs/cgroup/system.slice/nginx.service/memory.current

cgroup 的限制粒度很细，但复杂点在于：它管的是“资源归属”，不是“资源使用方式”。同一个进程调用 malloc 和 mmap，内核计费逻辑不同；Python 的垃圾回收时机也会影响 memory.current 的抖动。别只盯着数字，要结合 memory.stat 里的 pgmajfault、oom_kill 字段看真实压力来源。

好了，本文到此结束，带大家了解了《Linux如何用cgroup限制进程资源》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！