cgroups**（控制组），用于管理进程对 CPU 资源的使用权限

这段代码定义了两个 Linux cgroups（控制组），用于管理进程对 CPU 资源的使用权限。以下是逐行解析及核心机制说明：

---

一、基础概念

• cgroups：Linux 内核提供的一种机制，用于限制/统计进程组的资源使用（CPU、内存、磁盘 I/O 等）。
• cpu.shares：表示进程获取 CPU 时间的相对权重（非绝对数值），范围通常是 [1, 10^9]，默认值为 1024。

📌 关键特性：

• cpu.shares 仅在 多个进程竞争 CPU 资源 时生效（即系统繁忙时）。
• 如果只有一个进程运行，无论 shares 如何设置，它都能独占 CPU。
• 数值越大，相同条件下获得的 CPU 时间越长。

---

二、代码详解

✅ 第一组：lesscpu

group lesscpu {
    cpu {
        cpu.shares=200;
    }
}

• 功能：创建一个名为 lesscpu 的控制组，将其内部进程的 CPU 权重设为 200。
• 行为：
  • 当该组内的进程与其他组（如 morecpu）的进程竞争 CPU 时，按权重比例分配时间片。
  • 例如：若另一组的 cpu.shares=800，则两者比例为 200:800 = 1:4，即对方获得 4 倍于本组的 CPU 时间。

✅ 第二组：morecpu

group morecpu {
    cpu {
        cpu.shares=800;
    }
}

• 功能：创建一个名为 morecpu 的控制组，将其内部进程的 CPU 权重设为 800。
• 行为：
  • 相比 lesscpu 组，此组进程在竞争 CPU 时具有更高的优先级。
  • 若两组进程同时运行且系统负载高，morecpu 组的进程会更频繁地获得 CPU 时间。

---

三、典型应用场景

场景	适用策略	优势
后台低优先级任务	放入 lesscpu 组 (shares=200)	避免抢占前台关键任务的 CPU 资源
核心业务服务	放入 morecpu 组 (shares=800)	确保高吞吐需求的服务获得充足算力
混合部署环境	结合两组隔离不同类型的工作负载	平衡资源利用率与服务质量

---

四、注意事项

1. 绝对 vs 相对限制：

   • cpu.shares 不保证最小带宽，仅决定竞争时的优先级。
   • 如需严格限制 CPU 上限，应配合 cpu.cfs_quota_us（微秒级限额）。

2. 父子关系影响：

   • 如果两组嵌套（如 morecpu 是 lesscpu 的子组），最终生效的是子组的配置。
   • 独立并列的组才按各自 shares 竞争。

3. 默认行为：

   • 未加入任何 cgroup 的进程继承根 cgroup 的配置（通常 cpu.shares=1024）。

---

五、示例对比

假设以下条件：

• 系统仅有 lesscpu 和 morecpu 两组进程。
• 两组各有 1 个进程持续占用 CPU。
• 总可用 CPU 时间为 100ms。

组名	cpu.shares	理论分配比例	实际获得时间
lesscpu	200	200 / (200+800) = 20%	20ms
morecpu	800	800 / (200+800) = 80%	80ms

⚠️ 注意：实际分配受调度器算法、其他干扰任务等因素影响，以上仅为理想模型。

---

六、扩展建议

• 硬性限制：添加 cpu.cfs_quota_us=50000 可限制进程每秒最多使用 50ms CPU 时间（适合防止暴走任务）。
• 监控工具：使用 docker stats、top 或 pidstat 观察各组的实际 CPU 使用率。
• 动态调整：通过 API 或脚本实时修改 cpu.shares 适应负载变化。

---

总结

这段代码通过 cpu.shares 实现了差异化的 CPU 资源竞争力度：

• lesscpu 组：低优先级，适合轻载任务。
• morecpu 组：高优先级，适合核心服务。
  这种设计常用于云原生环境中实现资源隔离和 QoS（服务质量）保障。