cgroup 是 Linux 内核的资源管理机制，用于限制、统计和隔离进程组的 CPU、内存、IO、网络等资源；默认配置保守，生产中需调优以避免资源争抢、OOM 和延迟升高，确保关键服务稳定可预测运行。
什么是 cgroup 及为什么需要调优
cgroup（Control Groups）是 Linux 内核提供的资源管理机制，用于对进程组进行 CPU、内存、IO、网络等资源的限制、统计和隔离。默认配置往往偏保守或通用，生产环境中若不调优，容易出现资源争抢、OOM 杀进程、CPU 饱和却响应延迟高等问题。调优目标不是压榨极限，而是让关键服务稳定、可预测地运行。
CPU 资源隔离：避免“吵闹邻居”干扰
通过 cpu.cfs_quota_us 和 cpu.cfs_period_us 控制 CPU 时间配额，比单纯用 nice 值更可靠。例如，限制某容器最多使用 2 个逻辑 CPU：
- 设置 cpu.cfs_period_us = 100000（即 100ms 周期）
- 设置 cpu.cfs_quota_us = 200000（200ms/100ms = 2 核）
- 对延迟敏感服务（如 Redis），建议搭配 cpu.rt_runtime_us 启用实时调度（需内核开启 CONFIG_RT_GROUP_SCHED）
- 避免将 cpu.shares 设得过高又不限制 quota，否则在多组竞争时仍可能抢占过多时间
内存隔离：防 OOM 与内存抖动
内存是最易触发异常的资源，调优重点在于预防突发申请导致整个 cgroup 被 kill：
- 必须设置 memory.max（cgroup v2 推荐）或 memory.limit_in_bytes（v1），而非仅靠 memory.soft_limit_in_bytes
- 预留缓冲：设 memory.low 保障关键缓存不被轻易回收；设 memory.min 锁定不可回收内存（如共享页缓存）
- 关闭 memory.swappiness=0（尤其对数据库类应用），防止主动换出到 swap 导致延迟飙升
- 监控 memory.events 中的 oom_kill 计数，一旦非零立即检查配额是否过紧或存在内存泄漏
IO 与 PID 隔离：补全关键维度
仅做 CPU 和内存隔离常不够，IO 瓶颈和进程爆炸同样致命：
- 用 io.max（v2）按设备+权重/带宽限速，例如限制某后台任务对 nvme0n1 的写入不超过 10MB/s
- 设置 pids.max 防止 fork 炸弹耗尽全局 pid 数（默认无限制），建议按服务预期最大并发进程数 +20% 设置
- 对混合负载场景，启用 io.weight 实现 IO 优先级调度，比 legacy 的 blkio.weight 更精准
- 注意：部分云环境（如某些 Kubernetes 节点）可能禁用 io.weight，需提前验证内核支持及挂载选项
验证与持续观察才是调优闭环
所有参数上线后必须验证效果，不能只看“没报错”：
- 用 systemd-cgtop 或 cat /sys/fs/cgroup/xxx/cpu.stat 查看实际使用率与 throttled_time（被节流时间）
- 通过 perf stat -e sched:sched_stat_runtime 观察进程真实 CPU 运行时长分布
- 将 cgroup 指标（如 memory.current、io.stat）接入 Prometheus + Grafana，设置 throttling > 5% 或 oom_kill > 0 的告警
- 每次变更只调整一个维度，记录前后延迟 P99、吞吐变化，避免多变量干扰判断
