纯cgroup-v2模式需内核参数systemd.unified_cgroup_hierarchy=1；挂载命令为mount -t cgroup2 none /sys/fs/cgroup；资源控制通过cgroup.subtree_control启用后写cpu.weight、cpu.max、memory.max等文件实现。
如何创建 cgroup-v2 控制组并挂载到 /sys/fs/cgroup
Linux 5.10+ 默认启用 cgroup-v2，但部分发行版（如 CentOS 8 Stream、Ubuntu 22.04）仍可能默认使用 legacy 混合模式。必须确认当前是纯 v2 模式，否则 cgroup.procs 写入会失败或行为异常。
检查方法：mount | grep cgroup —— 若只看到一行 cgroup2 on /sys/fs/cgroup type cgroup2，说明是纯 v2；若同时存在 cgroup on /sys/fs/cgroup/systemd 等多挂载点，则需强制切换。
- 启动时加内核参数：
systemd.unified_cgroup_hierarchy=1，并确保systemd.legacy_systemd_cgroup_controller=0 - 运行中无法热切，只能重启生效
- 挂载命令（通常无需手动执行，但调试时可用）：
mkdir -p /sys/fs/cgroup && mount -t cgroup2 none /sys/fs/cgroup
如何限制 CPU 和内存资源（cgroup-v2 的核心配置项）
cgroup-v2 把资源控制收敛到统一接口，不再有 cpu.shares 或 memory.limit_in_bytes 这类 v1 风格路径。所有控制都通过写入 cgroup.subtree_control 启用子系统后，在对应子目录下操作。
典型流程：创建子组 → 启用子系统 → 设置限额 → 加入进程
- 启用子系统：
echo "+cpu +memory" > /sys/fs/cgroup/myapp/cgroup.subtree_control - CPU 限制（权重方式，非硬上限）：
echo 50 > /sys/fs/cgroup/myapp/cpu.weight（范围 1–10000，默认 100） - CPU 硬限（推荐）：
echo "100000 50000" > /sys/fs/cgroup/myapp/cpu.max（表示每 100ms 最多用 50ms） - 内存硬限：
echo "512M" > /sys/fs/cgroup/myapp/memory.max（支持 K/M/G/B 单位，max表示硬上限，high是软限触发回收） - 写入进程：
echo $PID > /sys/fs/cgroup/myapp/cgroup.procs（注意是cgroup.procs，不是tasks）
为什么 cgroup.procs 写入失败或进程“逃逸”
这是最常踩的坑：v2 中 cgroup.procs 只接受线程组 leader 的 PID（即主线程 PID），且该进程不能处于不可中断睡眠（D 状态）、不能已属于其他 v2 cgroup、也不能是 init 进程（PID 1）。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
常见错误现象：Invalid argument、No such process、写入后立即从 cgroup.procs 消失。
- 确认进程状态：
ps -o pid,tid,comm,state -p $PID，确保 state 是R或S - 检查是否已被其他 cgroup 管理：
cat /proc/$PID/cgroup，输出应只有一行，且挂载点为/sys/fs/cgroup - 避免 shell 启动后直接写入：bash 子 shell 的 PID 易变，建议用
sh -c 'exec sleep infinity' & echo $! > cgroup.procs类方式稳定获取 PID - 容器场景下，Docker/Podman 默认用 v2，但若启用了
systemd驱动且未设Delegate=yes，会导致子 cgroup 创建失败
如何组合网络与 IO 隔离（cgroup-v2 的现实局限）
cgroup-v2 原生不提供网络带宽控制（net_cls、net_prio 是 v1 特性，v2 中已移除），IO 限速虽支持（io.max），但依赖 blkio 调度器（如 mq-deadline 或 bfq），在 NVMe 或某些云盘上可能无效。
这意味着：纯 cgroup-v2 无法实现端到端多维隔离，必须配合其他机制。
- 网络限速必须靠
tc+iptables+ cgroup2 的net_cls替代方案（如用cgroup2的pid关联tc filter匹配进程所属 cgroup） - IO 限速前先确认设备类型：
cat /sys/block/nvme0n1/queue/scheduler，若为[none]，需改用bfq并加载内核模块 -
io.max格式严格：MAJ:MIN rbps wbps riops wiops，例如8:0 10485760 0 0 0表示 sda 读带宽 10MB/s - 没有“CPU + 内存 + 网络”三位一体的原子控制组，实际部署需分层：cgroup-v2 控制 CPU/内存，
tc控制网络，io.max控制磁盘（且要验证生效）
真正麻烦的地方不在配置语法，而在于各子系统生效前提不一致——CPU 权重即时响应，内存限值触发 OOM killer 有延迟，IO 限速依赖底层队列策略，网络则完全游离在外。调一个参数，得查三处日志、验两个指标、等一次负载波动才能确认是否真起效。
