Linux系统负载与uptime查看方法

Linux系统平均负载（load average）并非CPU使用率，而是1/5/15分钟内平均处于运行（R）或不可中断睡眠（D）状态的进程/线程数量，其数值需结合CPU核心数判断是否异常——例如8核机器长期负载超5.6（0.7×8）即提示持续承压；尤其要注意高负载却低CPU占用的典型场景，往往源于I/O阻塞（如磁盘/NFS卡顿），此时应立即用iostat和ps -eo stat,pid,comm | grep " D "定位D态进程，而非盲目优化CPU；uptime只是问题入口，真正诊断必须依据三值趋势（上升/下降/平稳）、实时/proc/loadavg第四字段及配套工具链深入归因。

直接看 uptime 输出末尾的三个浮点数，就是系统平均负载；但光看数字没用，必须结合 CPU 核心数判断是否真有问题。

uptime 命令输出的三个数值到底是什么

执行 uptime 后，你看到类似这样的结果：

21:31:45 up 12 days,  7:22,  2 users,  load average: 2.45, 1.89, 1.33

这三个数不是 CPU 使用率，也不是百分比，而是单位时间内处于以下两种状态的进程（准确说是线程）的平均数量：

• R 状态：正在运行或就绪等待 CPU 调度（Running/Runnable）
• D 状态：不可中断睡眠，通常卡在 I/O（如磁盘读写、NFS 响应）（Uninterruptible Sleep）

它们采用指数加权移动平均（EWMA）计算，每 5 秒采样一次。因此：

• 2.45（1 分钟）对突发变化最敏感，可能只是临时任务
• 1.89（5 分钟）反映中短期趋势，诊断价值最高
• 1.33（15 分钟）衰减最慢，代表长期稳定压力

怎么知道该用哪个数值做判断

单看某个值容易误判。重点看三者关系和持续时间：

• 如果 1.33 > 1.89 > 2.45：负载在下降，大概率刚结束一批任务
• 如果 2.45 > 1.89 > 1.33：负载在快速上升，需立即关注
• 如果三者接近且都 > 0.7 × CPU 核心数：说明系统已持续承压，不是瞬时抖动

例如一台 8 核机器，load average: 4.1, 3.9, 3.7 表示压力正缓和；而 6.2, 6.5, 6.8 就意味着过去 15 分钟内，平均有近 7 个进程在争抢 CPU 或卡在 I/O，已逼近瓶颈。

为什么 load 高但 %Cpu(s) 很低

这是最常被误解的情况。高负载 ≠ 高 CPU 使用率。当大量进程卡在 D 状态（比如等待慢盘响应、NFS 超时、驱动挂起），它们不消耗 CPU 时间，但会计入 load。此时你会看到：

• uptime 或 top 显示 load > 核心数
• %Cpu(s): 95.7 id（空闲率很高）
• iostat -x 1 中 %util 接近 100% 或 await 异常高

验证方法：

• 查 D 状态进程：ps -eo stat,pid,comm | grep " D "
• 看当前就绪+不可中断进程数：cat /proc/loadavg 第四字段（如 2/124 中斜杠前的 2）

别只盯着 uptime，下一步该做什么

uptime 是第一道筛子，不是终点。它告诉你“有问题”，但不告诉你“哪出问题”。接下来必须分情况跟进：

• 如果 load 高 + CPU 使用率也高 → 用 top 按 P 排序，找 %CPU 高的进程
• 如果 load 高 + CPU 使用率低 → 用 iostat -x 1 查 I/O 延迟，用 ps 找 D 状态线程
• 如果 load 值本身不高（如 0.3, 0.4, 0.5）但服务变慢 → 可能是单个进程锁竞争、内存换页、网络延迟等，load 不敏感

真正容易被忽略的是：/proc/loadavg 的第四字段（就绪+D态进程实时计数）比 uptime 的三个平均值更及时，适合脚本监控突增；而 15 分钟值是否持续高于核心数，比 1 分钟值冲到 10 更值得干预。

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