Linux 组调度的 tg_load_avg：任务组的平均负载计算

前言

在云原生、多租户、容器化的服务器架构中，Linux CFS 组调度已经成为 CPU 资源隔离与公平分配的基石。tg_load_avg作为任务组（task_group）的核心负载指标，负责聚合组内所有进程 / 线程在所有 CPU 上的负载，为内核负载均衡、CPU 频率调节、组间公平调度提供精准的组级负载依据。不理解 tg_load_avg，就无法真正读懂容器 CPU 调度、负载抖动、热点迁移的底层逻辑。

本文面向 Linux 入门开发者，以实战可复现、原理可理解、问题可解决为目标，完整拆解 tg_load_avg 的定义、计算逻辑、数据来源、观测方法与最佳实践，全程提供可复制命令、可运行案例、可对照排错，帮你从零掌握任务组负载计算的核心技能。

一、简介：为什么必须掌握 tg_load_avg？

1.1 技术背景

Linux CFS 组调度允许将进程划分为 task_group，以组为单位分配 CPU 份额（shares）、限制 CPU 带宽（quota/period）。为了在多核之间做负载均衡、在组间做公平调度、在系统层面做能效调控，内核必须知道每个任务组整体有多 “忙”，而不是只看单个进程或单个 CPU。

tg_load_avg 应运而生：它是 task_group 结构体中的全局负载平均值，由内核通过 PELT（Per-Entity Load Tracking）算法实时计算，代表任务组在全系统范围内的 CPU 负载总和。

1.2 实际应用场景

• 容器 CPU 调度：Docker/K8s 的 CPU 权重、负载均衡、热点调度，底层依赖 tg_load_avg 做组负载判断。
• 多核负载均衡：内核迁移任务时，以 tg_load_avg 判断哪个组更忙，避免组内任务集中在个别核心。
• CPU 频率调控：intel_pstate/amd_pstate 驱动根据组负载调整频率，高负载组提升频率，低负载组降频省电。
• 性能排查：定位 “系统不忙但容器卡顿”“负载不均导致延迟飙高” 等问题，必须观测 tg_load_avg。
• 多租户隔离：按组负载实现优先级调度，保证核心业务组获得稳定 CPU 资源。

1.3 对开发者的价值

• 读懂 Linux 组调度的负载传递链路：任务 → CPU 运行队列 → 任务组 → 全局调度。
• 具备容器 / 进程负载异常的根因定位能力。
• 掌握 CPU 份额、负载均衡、频率调节的底层依据，实现更稳定的服务部署。
• 从 “会用命令” 升级为 “懂原理、能调优、能排障” 的 Linux 性能工程师。

二、核心概念：零基础读懂 tg_load_avg

2.1 基础概念总览

2.2 tg_load_avg 的官方定义

tg_load_avg 是struct task_group中的atomic_long_t load_avg字段，代表整个任务组在所有 CPU 上的总负载平均值。它不是瞬时值，而是经过 PELT 衰减的平滑值，避免抖动，适合调度决策。

内核官方计算逻辑（简化）：

plaintext

tg_load_avg = SUM(每个 CPU 上该组 cfs_rq 的负载贡献)

2.3 负载计算的完整链路（自底向上）

1. 任务负载：单个线程 / 进程通过 PELT 计算se.avg.load_avg。
2. CPU 队列负载：同一 CPU 上所有任务负载汇总为cfs_rq.avg.load_avg。
3. 组负载贡献：每个 CPU 上的 cfs_rq 向所属 task_group 上报负载tg_load_contrib。
4. 组全局负载：task_group 汇总所有 CPU 的贡献，得到tg_load_avg。

2.4 关键特性

• 全局唯一：一个 task_group 只有一个 tg_load_avg，不区分 CPU。
• 平滑衰减：使用指数加权移动平均，避免瞬间毛刺。
• 非实时更新：内核只在负载变化超过阈值（1/64）时更新，降低开销。
• 决策依据：负载均衡、组调度权重、频率调节的核心输入。

三、环境准备：实战环境搭建（新手可直接复制）

3.1 软硬件要求

• OS：CentOS 7/8、Ubuntu 18.04+、Debian 10+
• 内核：≥ 3.2（推荐 4.0+，PELT 与组调度成熟）
• 内核配置：
  • CONFIG_FAIR_GROUP_SCHED=y
  • CONFIG_CGROUP_SCHED=y
  • CONFIG_CFS_BANDWIDTH=y
• 工具：cgroup-tools、stress、sysstat、debugfs
• 权限：root 权限

3.2 安装依赖工具

# CentOS / RHEL yum install -y libcgroup-tools sysstat stress # Ubuntu / Debian apt-get install -y cgroup-tools sysstat stress

3.3 挂载 cgroup 与 debugfs

# 挂载 CPU cgroup（v1） mkdir -p /sys/fs/cgroup/cpu mount -t cgroup -o cpu cpu /sys/fs/cgroup/cpu # 挂载 debugfs（用于查看 tg_load_avg） mount -t debugfs debugfs /sys/kernel/debug

3.4 验证环境

# 验证 cfs 文件 ls /sys/fs/cgroup/cpu | grep cfs # 验证 debugfs 调度信息 cat /sys/kernel/debug/sched/debug | head -10

出现cpu.cfs_period_us、cpu.stat等文件，说明环境正常。

四、实际案例与步骤：tg_load_avg 完整观测与验证

案例目标

创建任务组 → 运行压测进程 → 观测 tg_load_avg 随负载上升 / 下降 → 验证负载聚合逻辑 → 清理环境。

4.1 步骤 1：创建任务组

# 创建任务组目录 mkdir -p /sys/fs/cgroup/cpu/demo_tg # 设置 CPU 份额（默认 1024，可不改） echo 1024 > /sys/fs/cgroup/cpu/demo_tg/cpu.shares # 查看配置 echo "CPU shares: $(cat /sys/fs/cgroup/cpu/demo_tg/cpu.shares)"

作用：创建名为 demo_tg 的任务组，用于隔离测试进程。

4.2 步骤 2：运行压测进程并加入组

# 后台运行 1 核 CPU 密集任务 stress -c 1 & # 获取 PID PID=$(ps -ef | grep stress | grep -v grep | awk 'NR==1{print $2}') echo "stress PID: $PID" # 将进程加入任务组 echo $PID > /sys/fs/cgroup/cpu/demo_tg/cgroup.procs # 验证加入成功 cat /sys/fs/cgroup/cpu/demo_tg/cgroup.procs

作用：产生稳定负载，让 tg_load_avg 明显上升。

4.3 步骤 3：观测 tg_load_avg（核心步骤）

方法 1：通过 debugfs 直接查看（最准确）

# 过滤任务组信息，查看 tg_load_avg cat /sys/kernel/debug/sched/debug | grep -A 30 "demo_tg"

预期输出：

plaintext

demo_tg task_group: load_avg: 1023 # 这就是 tg_load_avg shares: 1024 ...

• 无负载时：load_avg ≈ 0
• 1 核满负载：load_avg ≈ 1024（NICE_0_LOAD 标准负载）

方法 2：周期性观测变化

# 每 0.5 秒输出一次 tg_load_avg for ((i=0;i<20;i++)); do echo -n "[$i] " cat /sys/kernel/debug/sched/debug | grep -A 10 "demo_tg" | grep load_avg sleep 0.5 done

现象：

• 进程刚加入：负载快速上升
• 稳定运行：负载维持在 1024 左右
• 停止 stress：负载缓慢衰减

4.4 步骤 4：验证多进程负载聚合

再启动一个 stress，观察 tg_load_avg 翻倍：

stress -c 1 & PID2=$(ps -ef | grep stress | grep -v grep | awk 'NR==2{print $2}') echo $PID2 > /sys/fs/cgroup/cpu/demo_tg/cgroup.procs # 再次观测 cat /sys/kernel/debug/sched/debug | grep -A 10 "demo_tg" | grep load_avg

结果：tg_load_avg ≈ 2048，证明组负载会正确聚合所有任务。

4.5 步骤 5：内核核心逻辑（简化源码）

以下是内核更新 tg_load_avg 的关键逻辑，帮助理解原理：

// 从每个 CPU 的 cfs_rq 向 task_group 上报负载 static void update_tg_load_avg(struct cfs_rq *cfs_rq) { struct task_group *tg = cfs_rq->tg; long contrib = cfs_rq->runnable_load_avg + cfs_rq->blocked_load_avg; long delta = contrib - cfs_rq->tg_load_contrib; // 变化超过 1/64 才更新，避免频繁计算 if (abs(delta) > cfs_rq->tg_load_contrib / 64) { atomic_long_add(delta, &tg->load_avg); cfs_rq->tg_load_contrib = contrib; } }

解释：

• 每个 CPU 队列计算自己对组的贡献。
• 只有变化足够大时才更新 tg_load_avg。
• 最终 tg_load_avg = 所有 CPU 贡献之和。

4.6 步骤 6：清理环境

# 终止压测 pkill stress # 删除任务组 rmdir /sys/fs/cgroup/cpu/demo_tg

五、常见问题与解答（实战高频）

问题 1：看不到 tg_load_avg 字段？

原因：未挂载 debugfs 或 grep 过滤错误。解决：

mount -t debugfs debugfs /sys/kernel/debug cat /sys/kernel/debug/sched/debug | grep -A 30 "你的组名"

问题 2：负载为 0，但进程在运行？

原因：

• 任务刚加入，还未到更新周期（16ms PELT 周期）。
• 任务是 I/O 型，CPU 占用极低。解决：等待几秒，或使用stress -c纯 CPU 压测。

问题 3：多 CPU 环境，负载不随核心数线性增长？

原因：内核负载均衡会把任务分散到不同核心，PELT 平滑会延迟反应。解决：这是正常现象，tg_load_avg 最终会趋近于核心数 × 1024。

问题 4：tg_load_avg 很高，但容器 CPU 使用率低？

原因：

• 被 cfs_quota 限流，runtime_remaining 耗尽。
• 任务在休眠态，负载计入但不占用 CPU。解决：查看cpu.stat中的throttled_time。

问题 5：任务迁移后，tg_load_avg 多久收敛？

答案：PELT 衰减周期约 16ms，通常3~5 个周期（约 50ms）收敛。

六、实践建议与最佳实践

6.1 观测最佳实践

• 优先用 debugfs：最直接、最准确反映内核真实 tg_load_avg。
• 结合 cpu.stat：nr_running、throttled_time配合负载判断瓶颈。
• 长期监控：用 Prometheus + node_exporter 采集组负载，做趋势分析。

6.2 配置最佳实践

• shares 不要极端：核心业务设 2048，非核心设 512，避免 1/999 极端值。
• 避免过小周期：cfs_period_us 保持默认 100ms，降低调度开销。
• 多核心部署：让任务组跨多核运行，tg_load_avg 更平稳，调度更公平。

6.3 性能调优技巧

• 负载不均优化：tg_load_avg 在个别核心很高 → 开启内核自动负载均衡（默认开启）。
• 限流优化：tg_load_avg 高但 throttled_time 增长 → 提高 cfs_quota_us。
• 延迟优化：核心组保持 tg_load_avg 稳定，避免突刺导致调度延迟。

6.4 调试技巧

• 快速复现负载：stress -c N快速生成稳定负载。
• 跟踪内核函数：perf trace -p PID update_tg_load_avg观察负载更新。
• 衰减观察：停止任务后，观察 tg_load_avg 平滑下降，理解 PELT 特性。

七、总结与应用场景

7.1 核心要点回顾

1. tg_load_avg 是什么：task_group 的全局平均负载，聚合所有 CPU、所有任务的负载。
2. 怎么计算：自底向上汇总，PELT 平滑，阈值更新，保证高效准确。
3. 用来做什么：负载均衡、组调度、频率调节、容器调度的核心依据。
4. 怎么观测：debugfs 直接查看，配合 stress 可复现验证。

7.2 核心应用场景

• 云原生容器：K8s CPU 管理、Docker 资源限制底层依赖。
• 多核服务器：保证任务组在多核间公平占用，避免热点核心。
• 实时性系统：用 tg_load_avg 判断负载，保证关键任务低延迟。
• 性能诊断：定位 “负载高但 CPU 低”“负载不均”“限流导致卡顿”。

7.3 学习路径建议

1. 先跑通本文案例，直观理解 tg_load_avg 变化。
2. 阅读内核简化代码，理解自底向上的负载链路。
3. 在生产环境观测业务组的 tg_load_avg，结合监控做优化。
4. 延伸学习：PELT 算法、cfs_rq 负载、组调度层级结构。

掌握 tg_load_avg，你就掌握了 Linux 组调度的负载视角，能够从内核层面理解 CPU 资源分配，成为真正能解决复杂性能问题的工程师。