Linux怎么使用cgroup_Linux如何限制进程资源使用量【方法】-LINUX-PHP中文网

cgroup v2 是 linux 下限制进程 cpu 和内存的现代可靠方式，需通过 systemd-run 启动带 cpuquota 和 memorymax 限制的进程，或修改服务单元文件；memory.max 非硬杀限，超限后分配失败或触发 oom，须设 memory.swap.max=0 才严格限制物理内存。

linux怎么使用cgroup_linux如何限制进程资源使用量【方法】

怎么用 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 字段看真实压力来源。