linux容器资源管理核心是 cgroups 内核级强制隔离，CPU 通过 cfs_period_us 与 cfs_quota_us 控制（如 quota=200000/period=100000= 2 核），内存需同时设 memory.limit_in_bytes 和 memory.memsw.limit_in_bytes 防 swap 绕过，绑定推荐 cgexec 启动，验证须查 cgroup 原生 接口 而非 top。
Linux 容器资源管理的核心，就是靠 cgroups 实现的硬性隔离与精准控制。它不是“建议”或“调度倾向”，而是内核级强制限制——超限就杀进程（如内存 OOM）、超时就暂停调度（如 CPU 配额用尽）。理解关键参数和操作逻辑，比死记命令更重要。
CPU 限制：别只看百分比，要看周期与配额
cgroups 控制 CPU 不是靠“占用率”这个结果，而是通过 cfs_period_us（调度周期）和 cfs_quota_us（该周期内允许使用的 CPU 时间）两个值共同决定的。实际可用 CPU 核心数 = quota / period。
- 默认周期是 100000 微秒（即 100ms），若设 quota = 50000，则等效为 0.5 个核心（50% 单核）
- 想限制为 2 个完整核心：quota = 200000，period = 100000
- 想限制为 4 核服务器上的 75% 总算力（即 3 核）：quota = 300000，period = 100000
- 注意：quota 可大于 period，但不能小于 1000（即 1ms），否则会被内核拒绝
内存限制：物理上限 + swap 容量要分开管
内存控制的关键文件是 memory.limit_in_bytes，但它只管物理内存。如果不限制 swap，进程仍可能把数据换出到磁盘，绕过物理内存限制。
- 设物理内存上限为 2GB：echo 2147483648 > memory.limit_in_bytes
- 同时限制“内存 +swap”总和为 2.5GB：echo 2684354560 > memory.memsw.limit_in_bytes
- 一旦进程申请内存导致总用量突破 memsw 上限，OOM Killer 就会介入并终止最“可杀”的进程
- 不建议关闭 swap，但必须显式配置 memsw，否则 memory.limit_in_bytes 形同虚设
绑定进程：启动时绑定比运行中迁移更可靠
把服务进程纳入 cgroup，有两种主流方式，推荐优先用第一种：
- 用 cgexec 启动：sudo cgexec -g cpu,memory:/myapp ./myserver —— 进程从诞生起就受控，无遗漏风险
- 用 cgclassify 迁移已有进程：sudo cgclassify -g cpu,memory:myapp $(pgrep myserver) —— 需确认 PID 准确，且子进程未必自动 继承
- systemd 用户可直接在 service 文件里加 Slice= 字段，让整个服务天然落入指定 cgroup 层级
验证与调试：别只信 top，要用原生接口查
top、htop 显示的是瞬时负载，无法反映 cgroups 的真实配额执行情况。应直接读取 cgroup 接口文件或使用 pidstat：
- 查某 cgroup 当前 CPU 使用总量：cat cpu.stat（含 nr_periods、nr_throttled、throttled_time）
- 查是否被限频：throttled_time > 0 表示该组已被 throttle 过
- 查内存实际用量：cat memory.usage_in_bytes 和 cat memory.max_usage_in_bytes
- 用 pidstat -r -p $(pgrep myapp) 看 RSS 是否逼近 limit_in_bytes
基本上就这些。cgroups 不复杂但容易忽略细节，尤其是 period/quota 的数学关系和 memsw 的必要性。只要参数设对、绑定及时、验证到位，容器资源就不会“飘”。
