Linux资源配额策略需协同cgroups v2（内核级）、systemd（服务级）和ulimit（用户级）三层控制：cgroups v2统一管理CPU、内存、进程数等硬限制；systemd通过unit文件持久化配置并自动托管；ulimit提供轻量会话级软限制，三者配合实现稳健资源管控。
Linux 调整进程组资源配额控制策略，核心是围绕 cgroups（Control Groups） 展开，辅以 systemd 集成配置 和 ulimit 用户级限制。不同层级的控制适用于不同场景：内核级隔离用 cgroups，服务级管控靠 systemd，用户会话级约束靠 ulimit。三者配合使用，才能实现真正稳健的资源配额策略。
用 cgroups v2 统一管理进程组资源
现代 Linux 发行版（如 Ubuntu 22.04+、CentOS 8+、RHEL 9+）默认启用 cgroups v2，它采用统一层级结构，避免 v1 多挂载点的混乱。确认是否启用： ```bash cat /sys/fs/cgroup/cgroup.controllers ``` 若输出含 `cpu`、`memory`、`io`、`pids`，说明支持完整功能。- 创建控制组目录（例如限制某批后台任务）：
sudo mkdir -p /sys/fs/cgroup/limit_batch
- 设置 CPU 配额（限制为 1 个逻辑核的 60%）：
echo "60000" | sudo tee /sys/fs/cgroup/limit_batch/cpu.max
- 设置内存上限（2GB，含 swap）：
echo "2147483648" | sudo tee /sys/fs/cgroup/limit_batch/memory.max
- 设置最大进程数（防 fork 炸弹）：
echo "50" | sudo tee /sys/fs/cgroup/limit_batch/pids.max
- 将已有进程加入该组（如 PID 1234）：
echo 1234 | sudo tee /sys/fs/cgroup/limit_batch/cgroup.procs
注意：cgroups v2 中 cpu.max 格式为 <quota> <period>（单位微秒），60000 100000 表示每 100ms 最多运行 60ms；若只写一个值（如 60000），系统默认 period=100000。
通过 systemd 持久化服务资源配额
对长期运行的服务（如 nginx、redis、自定义脚本），推荐在 unit 文件中声明配额，由 systemd 自动托管 cgroups：- 编辑服务文件（如
/etc/systemd/system/myapp.service）：[Service] MemoryMax=1G CPUQuota=75% IOWeight=50 TasksMax=100
- 重载并重启：
sudo systemctl daemon-reload sudo systemctl restart myapp.service
systemd 会自动创建对应 cgroup 并绑定进程，且支持热更新（修改后 reload 即可生效）。相比手动操作，更安全、可审计、易维护。
按用户或登录会话设置基础资源边界
ulimit 是最轻量的用户级限制，适合防范 shell 会话中突发的资源滥用（如误执行无限循环、打开过多文件）：- 查看当前限制：
ulimit -a
- 临时调整（仅当前终端有效）：
ulimit -n 4096 # 最大文件描述符 ulimit -u 128 # 最大用户进程数
- 永久生效：编辑
/etc/security/limits.conf，例如：@developers soft nproc 200 @developers hard nproc 400 www-data hard memlock 524288
注意：需确保 PAM 模块已启用
pam_limits.so（通常/etc/pam.d/common-session中有该行）。
动态监控与验证配额效果
配额设完不等于生效，必须验证：- 查看某进程所属 cgroup：
cat /proc/1234/cgroup
- 实时读取资源使用统计（v2 路径）：
cat /sys/fs/cgroup/limit_batch/cpu.stat cat /sys/fs/cgroup/limit_batch/memory.current cat /sys/fs/cgroup/limit_batch/pids.current
- 使用
systemd-cgtop或podman ps --cgroup-manager=cgroupfs（若装了 Podman）快速查看各 cgroup 资源占用。
关键提醒：
- cgroups 限制是硬性截断（如内存超限触发 OOM Killer，CPU 超额被节流），而 ulimit 是进程启动时检查，不具动态节制能力；
- systemd 配置优先级高于手动 cgroups 操作，避免混用冲突；
- 修改 limits.conf 后，新登录会话才生效，已登录用户需重新登录或
su - $USER切换。
不复杂但容易忽略细节。
