Linux /proc/loadavg 的 running 与 total 怎么读

看到 /proc/loadavg 中的 3/828，很多人会把 3 理解成“正在运行的进程”，把 828 理解成“进程数”。更准确的读法是：斜杠前是当前可运行的内核调度实体数量，斜杠后是系统当前存在的调度实体总数；它们通常包含线程，所以不能直接替代 CPU 使用率或 ps 的进程计数。

官方资料：https://docs.kernel.org/filesystems/proc.html

先把第四列拆成 running 与 total

可以先把内容按空格切成五列。下面的命令只做文本读取，不把示例输出当成固定值：

# 读取内核导出的负载行，并按空格拆出字段
read -r one five fifteen running_total last_pid 

例如 0.61 0.61 0.55 3/828 22084 中，3 是当前可运行实体数，828 是当前存在的调度实体数，22084 是最近创建的 PID。这里的“实体”很重要：Linux 的调度对象可以是进程，也可以是线程。一个多线程服务可能只对应一个用户态 PID，却贡献多个调度实体。

用 loadavg 和 CPU 数量一起判断是否真的拥堵

running 只能回答“当前有多少调度实体处于可运行状态”，不能回答“它们是否都在抢 CPU”。多核机器上，running 为 3 可能完全没有排队；单核机器上，running 长时间高于 1 才更值得关注。负载前三列还会把等待磁盘 I/O 的任务纳入统计，因此 load average 升高不一定是 CPU 算力不足。

# 查看逻辑 CPU 数量，作为负载的参照基线
cpu_count=$(getconf _NPROCESSORS_ONLN)

# 查看可运行线程与不可中断睡眠线程，辅助区分 CPU 和 I/O 方向
awk '/^procs_running |^procs_blocked / { print }' /proc/stat

# 查看进程状态，重点关注 R（运行）和 D（不可中断睡眠）
ps -eo state=,pid=,comm= --sort=state | awk '$1 ~ /^[RD]$/ { print }'

排查时可以采用一个简单的组合判断：

• 1 分钟值持续高于 5 分钟和 15 分钟，且 running 接近或超过逻辑 CPU 数量：优先检查 CPU 饱和、锁竞争和突发任务。
• load average 偏高但 procs_running 不高，同时 D 状态任务增多：优先检查磁盘、网络文件系统或块设备延迟。
• total 很大但负载不高：它只说明系统存在较多调度实体，不能单独证明系统变慢，应再看线程数量、内存和进程树。

还要留意容器和宿主机边界。容器内看到的 /proc、CPU 配额和 PID 命名空间可能改变观察范围；在容器里读取到的 running/total 不应未经核对就与宿主机的 uptime 或监控面板直接比较。

读取时最容易踩的三个边界

第一，第四列不是百分比，不能写成“3% 的 CPU”。第二，total 不是从开机到现在创建过的进程总量，进程退出后它会减少。第三，running 不是瞬时 CPU 执行槽位的计数，它是调度实体状态的快照；采样时刻不同，数字就可能变化。

生产排查可以把以下内容一起记录：连续几次的 /proc/loadavg、逻辑 CPU 数、/proc/stat 中的 procs_running、R/D 状态任务，以及容器的 CPU/PID 限制。这样才能把“负载变高”进一步收敛到 CPU 排队、I/O 等待或线程数量增长。

常见问题

running 是进程数还是线程数？

它是当前可运行的内核调度实体数，实践中应按进程和线程共同理解，不能只按 PID 数量解释。

total 越大，服务器就一定越慢吗？

不一定。total 只反映当前存在的调度实体数量，是否变慢还要结合 CPU、I/O、内存和任务状态。

为什么 load average 高但 CPU 使用率不高？

任务可能在等待磁盘或其他不可中断资源。此时重点看 D 状态任务和对应 I/O 延迟，而不是只增加 CPU。

记住一个速查句：先按字段位置读懂 running/total，再用 CPU 核数和 R/D 状态解释负载，最后用连续采样确认趋势。