linux内核任务调度器权重优化需分层控制：单进程用nice/chrt，整组业务必须用cgroup v2的cpu.weight（1–10000）动态调节比例，如800:100实现8:1分配，修改后通过sched_group_set_shares实时生效，避免仅调nice值的误区，并辅以cpu亲和性与sched_fifo加固关键路径。
Linux 内核任务调度器权重优化，核心是让关键业务进程或进程组获得更高比例的 CPU 时间，而不是简单调高单个进程的 nice 值。真正有效的做法是分层控制：对单进程用 nice/chrt，对整组业务（如一个容器、一个微服务集群）则必须用 cgroup 组调度机制，配合 shares 或 weight 参数动态调节资源配比。
cgroup v2 的 cpu.weight 是当前推荐方式
cgroup v2 已成为主流（尤其在 systemd 环境和容器运行时中），它用 cpu.weight（取值 1–10000，默认 100）替代了 v1 的 cpu.shares（取值 2–1024）。weight 是相对权重，比如数据库组设为 800、日志采集组设为 100，则两者 CPU 分配比约为 8:1。修改后立即生效，无需重启进程：
# 创建并配置关键业务组（以 systemd 为例） sudo systemctl set-property my-db.service CPUWeight=800 # 或直接写入 cgroup 接口（需挂载 cgroup2） echo 800 | sudo tee /sys/fs/cgroup/mydb/cpu.weight
CFS 调度器底层靠 sched_group_set_shares 实时落地权重
用户修改 cpu.weight 后，内核通过 sched_group_set_shares() 函数统一刷新该 task_group 在所有 CPU 上的调度实体（sched_entity）权重，并重平衡各 CPU 的 CFS 运行队列（cfs_rq）中虚拟运行时间（vruntime）的计算基准。这意味着权重变更会实时影响下一个调度周期的执行顺序，不是“平均分配”，而是持续按比例倾斜。
避免只调单进程 nice 值的常见误区
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- nice 值仅影响单个进程的静态优先级（prio = 120 + nice），且受动态补偿干扰（如交互型进程会被临时提权）；
- 当关键业务由数十个子进程（如 Java 应用的 GC 线程、Netty worker、metrics 上报线程）组成时，逐个 renice 不可持续、易遗漏、难维护；
- 更严重的是，nice 无法防止同组内低优先级进程拖慢整体响应——例如数据库主进程 high-nice，但其后台 vacuum 进程 low-nice，仍可能争抢 CPU。
结合 CPU 亲和性与调度策略加固关键路径
权重只是“比例保障”，还需辅以下列措施减少干扰：
- 将数据库主进程绑定到专用 CPU 核心（如
taskset -c 4-7），隔离其他业务干扰； - 对极低延迟要求的模块（如实时风控线程），改用
SCHED_FIFO并设高实时优先级（chrt -f 95），它完全绕过 CFS，优先级高于所有普通进程； - 确保内核启用
CONFIG_FAIR_GROUP_SCHED=y和CONFIG_RT_GROUP_SCHED=y（后者用于限制实时进程总带宽，防失控）。
验证是否生效的三步检查法
- 查看 cgroup 权重设置：
cat /sys/fs/cgroup/mydb/cpu.weight； - 观察实际 CPU 分配：
sudo cat /sys/fs/cgroup/mydb/cpu.stat | grep "usage_usec"，对比不同组的累计使用时间； - 检查调度行为：
sudo perf record -e sched:sched_stat_runtime -a sleep 10，再用perf script分析各组 runtime 占比是否符合预期权重比例。
