Linux系统负载怎么看？uptime与loadaverage解析

Linux系统中的load average并非CPU使用率，而是反映等待CPU或处于不可中断IO（D状态）的进程平均数量，判断其是否异常需结合CPU逻辑核心数——数值≤核心数属正常，持续超过1.5倍需关注，超2倍则大概率存在瓶颈；特别要注意三分钟负载值的动态趋势：1分钟值远高于15分钟值暗示突发尖峰，而15分钟值高、1分钟值低则提示缓慢堆积；当CPU使用率看似闲置但load却居高不下时，往往源于磁盘IO阻塞导致大量进程卡在D状态，此时应结合iostat和ps排查；/proc/loadavg是获取负载数据最轻量高效的方式，比uptime更适于脚本监控；若整体负载高但CPU总使用率不高，还需用mpstat -P ALL深入分析单核是否被独占——掌握这些关键逻辑，才能真正看懂Linux系统的“真实压力”。

怎么看 load average 数值是否异常

直接看 uptime 或 top 第一行的三个数字（如 load average: 2.45, 1.89, 1.32），它们分别代表过去 1 分钟、5 分钟、15 分钟的平均负载。这不是 CPU 使用率百分比，而是「等待 CPU 或不可中断 IO（D 状态）的进程平均数量」。

• 数值 ≤ CPU 逻辑核心数（可用 nproc 查）：系统宽松，一般没问题
• 数值持续 > 1.5 × 核心数：需关注；> 2 × 核心数：大概率存在瓶颈
• 特别警惕“1 分钟值远高于 15 分钟值”（如 7.2, 2.1, 1.9）：说明刚爆发过尖峰，可能已过去，但得立刻查当时在跑什么
• 反过来，15 分钟值高而 1 分钟低（如 0.8, 1.5, 3.6）：负载正在缓慢堆积，可能是内存泄漏或慢查询积累

为什么 top 显示 CPU 使用率不高，load 却很高

这是最常让人困惑的情况——%Cpu(s): 32.1 us, 4.2 sy, 0.0 ni, 63.5 id, 0.2 wa 看着很闲，但 load average: 8.6, 7.9, 7.2 却压在 8 以上。根本原因在于：load 统计的是「就绪队列 + 不可中断睡眠（D 状态）进程数」，而 CPU 使用率只算真正执行指令的时间。

• 典型诱因是磁盘 IO 卡住：进程在等磁盘读写完成（D 状态），不消耗 CPU，但计入 load
• 用 iostat -x 1 看 %util 和 await：若 %util 接近 100% 或 await > 50ms，基本锁定 IO 瓶颈
• 用 ps aux --sort=-pcpu | head -10 检查有没有大量 D 状态进程（STAT 列含 D）
• 注意：NVMe 盘的 %util 解读和 SATA 不同，高 util 不一定代表真瓶颈，要结合 avgqu-sz（平均队列深度）一起看

uptime 的 load 值从哪来？能直接读 /proc 吗

能，而且更轻量。Linux 内核把实时 load 值维护在 /proc/loadavg，uptime 就是读它。执行 cat /proc/loadavg 输出形如 3.21 2.88 2.65 3/124 12345，前三个是 load，第四个 3/124 表示「当前有 3 个可运行进程，系统共 124 个进程」，最后是最近创建的进程 PID。

• 脚本中建议直接读 /proc/loadavg 而非调 uptime，避免 fork 新进程、解析字符串的开销
• 注意：该文件无锁，多核下瞬时读取可能存在微小不一致，但对监控告警完全够用
• 不要误以为第四个数（如 3/124 中的 124）是总线程数——它包含所有状态的 task_struct，包括僵尸进程

单核高负载但其他核空闲？mpstat 要这样用

当整体 load 高、CPU 总使用率却不突出时，大概率是某个核心被独占。这时 top 默认聚合显示会掩盖问题，必须用 mpstat 拆开看每颗核。

• 运行 mpstat -P ALL 1 3：每秒采样一次，共三次，输出每颗逻辑 CPU 的详细占用
• 重点看 %usr + %sys 是否某颗核长期 >90%，而其他核
• 常见陷阱：容器环境里 mpstat -P ALL 显示的 CPU 编号是宿主机视角，和 docker stats 或 cgroup 的 cpuacct.stat 不对应，排查时要确认命名空间上下文
• 如果发现某核持续 100%，用 pidstat -t -p 1 追踪该进程下的线程级 CPU 分布，定位热点线程

好了，本文到此结束，带大家了解了《Linux系统负载怎么看？uptime与loadaverage解析》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！