第四篇：《CPU 深度调优：调度器、进程优先级与 Cgroups》

用工具发现了问题，下一步是解决问题。CPU 调优的核心是理解“CPU 时间是如何分配给各个进程的”——这取决于调度器的策略、进程优先级的设置，以及Cgroups的资源限制。本文深入讲解 Linux 的 CFS 调度器原理、nice 值与实时优先级、CPU 亲和性（taskset），以及容器时代最重要的 Cgroups v2 CPU 子系统，帮你从“被动发现”走向“主动调控”。

一、CFS 调度器：Linux 的“公平裁判”
1.1 什么是 CFS？
CFS（Completely Fair Scheduler，完全公平调度器） 是 Linux 内核从 2.6.23 版本开始使用的默认进程调度器。它的设计目标是：让所有进程公平地分享 CPU 时间。

1.2 CFS 的核心原理
CFS 摒弃了传统调度器复杂的优先级数组和轮转算法，采用了一个非常 elegant 的设计：

虚拟运行时间（vruntime） ：每个进程都有一个 vruntime 值，表示该进程已获得的 CPU 时间（经过优先级加权）。

红黑树（Red-Black Tree） ：CFS 将所有可运行进程按 vruntime 排序，vruntime 最小的进程被优先调度。

公平性保证：每次调度时，CFS 选择 vruntime 最小的进程运行。运行一段时间后，该进程的 vruntime 增加，会被放到树后面，让其他进程有机会运行。

简单来说：谁获得的 CPU 时间最少，谁就先运行。这就是“完全公平”的含义。

1.3 调度周期与时间片
CFS 不是用固定的时间片，而是根据目标延迟（target latency） 动态计算。例如：

目标延迟设为 20ms，系统中有 2 个可运行进程，每个进程获得约 10ms。

系统中有 10 个可运行进程，每个进程获得约 2ms。

进程数量越多，每个进程分到的时间片越短，上下文切换越频繁。

二、进程优先级：如何“插队”
虽然 CFS 追求公平，但 Linux 允许你通过优先级影响调度结果。

2.1 Nice 值（静态优先级）
nice 值是 Linux 中最常用的优先级调整方式，范围是 -20（最高优先级）到 19（最低优先级） ，默认值为 0。

nice 值 含义
-20 到 -1 高优先级（需要 root 权限或 CAP_SYS_NICE）
0 默认优先级
1 到 19 低优先级
nice 值影响的是 CFS 的 vruntime 增长速度：

nice 值越低 → vruntime 增长越慢 → 获得更多 CPU 时间

nice 值越高 → vruntime 增长越快 → 获得更少 CPU 时间

调整方式：

# 启动时设置 nice 值nice-n19make-j$(nproc)# 以最低优先级运行编译任务[reference:46]# 运行时调整（需要 root 权限降低 nice 值）renice-5-p1234# 将 PID 1234 的 nice 值调整为 -5[reference:47]sudorenice-10-p1234# 提高优先级[reference:48]

⚠️ 注意：普通用户只能提高 nice 值（降低优先级），不能降低 nice 值（提高优先级）。降低 nice 值需要 root 权限。

2.2 实时调度策略（chrt）
对于对响应时间有严格要求的任务（如音频处理、工业控制系统），可以使用实时调度策略。

# 查看进程的调度策略chrt-p1234# 设置 FIFO 实时调度策略，优先级 50（1-99）sudochrt-f-p501234# 以 RR 实时调度策略启动新进程sudochrt-r99./realtime_app

调度策略类型：

SCHED_OTHER：默认的 CFS 调度策略（普通进程）。

SCHED_FIFO：先进先出实时调度，高优先级进程会一直运行直到主动让出。

SCHED_RR：轮转实时调度，同优先级进程轮转执行。

⚠️ 警告：实时调度策略会抢占普通进程，使用不当可能导致系统卡死。仅用于经过充分测试的实时应用。

三、CPU 亲和性（taskset）：把进程“钉”在核心上
CPU 亲和性（CPU Affinity）是将进程绑定到特定 CPU 核心上运行。它的价值在于：

提升缓存命中率：进程始终在同一个核心上运行，L1/L2 缓存数据不会失效。

隔离关键业务：将核心业务进程绑定到独立核心，避免被其他进程干扰。

3.1 查看和设置 CPU 亲和性

# 查看进程的 CPU 亲和性taskset-p1234# 输出：pid 1234's current affinity mask: f（二进制 1111，表示可用 4 个核心）# 将进程绑定到 CPU 0 和 CPU 1taskset-cp0,11234# 启动新进程并绑定到 CPU 0-3taskset-c0-3 ./myapp

CPU 掩码：taskset 使用位掩码表示 CPU 核心。

掩码 1（二进制 0001）→ CPU 0

掩码 3（二进制 0011）→ CPU 0 和 CPU 1

掩码 f（二进制 1111）→ CPU 0-3

3.2 实战场景
场景一：将网络密集型进程绑定到专用核心

# 将网卡中断绑定到 CPU 2（需配置 /proc/irq/*/smp_affinity）# 将应用进程绑定到 CPU 3taskset-c3./nginx

场景二：NUMA 架构下的性能优化

在多路 CPU 服务器上，将进程绑定到同一个 NUMA 节点的核心上，可以避免跨节点内存访问的额外延迟。

# 查看 NUMA 拓扑numactl--hardware# 将进程绑定到 NUMA 节点 0 的 CPU 0-7numactl--cpunodebind=0--membind=0./myapp

四、Cgroups：容器时代的资源管控
Cgroups（Control Groups） 是 Linux 内核提供的资源限制机制，是 Docker 和 Kubernetes 实现资源隔离的底层技术。在生产环境中，你通常不会直接修改进程的 nice 值，而是通过 Cgroups 来限制容器的 CPU 使用。

4.1 Cgroups v2 CPU 子系统
Cgroups v2 是当前的主流版本，其 CPU 控制器通过两个核心文件控制资源：

文件 作用 示例
cpu.max 设置 CPU 配额（上限） 100000 100000 = 1 个 CPU 核心
cpu.weight 设置 CPU 权重（相对优先级） 范围 1-10000，默认 100
查看当前容器的 CPU 配额：

cat/sys/fs/cgroup/cpu.max# 输出：100000 100000（表示可以使用 1 个 CPU 核心）[reference:57]

cpu.max 的格式：

quota：在一个周期内允许使用的 CPU 时间（微秒）

period：周期长度（微秒，默认 100000）

quota / period = 可使用的 CPU 核心数

配置 含义
100000 100000 1 个 CPU 核心
50000 100000 0.5 个 CPU 核心
200000 100000 2 个 CPU 核心
max 100000 无限制（使用所有可用 CPU）
4.2 在容器环境中应用
Docker 限制 CPU：

dockerrun--cpus=2--cpu-shares=1024myapp

–cpus=2：限制容器最多使用 2 个 CPU 核心（对应 cpu.max）

–cpu-shares=1024：设置 CPU 权重（对应 cpu.weight）

Kubernetes 限制 CPU：

resources: requests: cpu:"500m"# 保证 0.5 个 CPU 核心limits: cpu:"1000m"# 最多使用 1 个 CPU 核心

requests：调度器保证的最小资源（软限制）

limits：容器允许使用的最大资源（硬限制，对应 cpu.max）

4.3 为什么 Cgroups 比 nice 更适合生产环境？

五、CPU 调优的层次与选择

最佳实践：

容器环境优先使用 Cgroups：通过 K8s 的 resources.limits 和 requests 声明式管理。

关键业务使用 taskset 隔离核心：将高优先级业务绑定到独立核心，避免被系统进程干扰。

临时调试使用 nice/renice：快速降低编译任务的优先级，不影响在线服务。

避免在生产环境随意使用实时调度：chrt 可能让系统失去响应。

六、小结
CFS 调度器通过 vruntime 实现进程间的公平调度。

nice 值（-20 到 19）影响进程的 CPU 时间分配，renice 可运行时调整。

taskset 将进程绑定到特定 CPU 核心，提升缓存命中率。

Cgroups v2 是容器时代资源管控的标准，通过 cpu.max 限制 CPU 配额。

理解这些机制，你就不仅能“看到” CPU 问题，还能主动“调控”CPU 资源分配。