uptime末尾三个浮点数是1/5/15分钟系统平均负载，表示单位时间内处于R或D状态的进程平均数量，需结合CPU核心数判断是否异常。
直接看输出末尾的三个浮点数，就是系统平均负载；但光看数字没用，必须结合 CPU 核心数判断是否真有问题。
uptime 命令输出的三个数值到底是什么
执行
后，你看到类似这样的结果：
这三个数不是 CPU 使用率，也不是百分比，而是单位时间内处于以下两种状态的进程（准确说是线程）的平均数量：
状态：正在运行或就绪等待 CPU 调度（Running/Runnable）
状态：不可中断睡眠，通常卡在 I/O（如磁盘读写、NFS 响应）（Uninterruptible Sleep）
它们采用指数加权移动平均（EWMA）计算，每 5 秒采样一次。因此：
（1 分钟）对突发变化最敏感，可能只是临时任务
（5 分钟）反映中短期趋势，诊断价值最高
（15 分钟）衰减最慢，代表长期稳定压力
怎么知道该用哪个数值做判断
单看某个值容易误判。重点看三者关系和持续时间：
如果
：负载在下降，大概率刚结束一批任务
如果
：负载在快速上升，需立即关注
如果三者接近且都 > 0.7 × CPU 核心数：说明系统已持续承压，不是瞬时抖动
例如一台 8 核机器，
表示压力正缓和；而
就意味着过去 15 分钟内，平均有近 7 个进程在争抢 CPU 或卡在 I/O，已逼近瓶颈。
Trae linux
Trae Linux 官方版本现已全面上线，开发者可直接访问 Trae 官网（trae.cn 国内版或 trae.ai 国际版）获取专属安装包。该版本完美适配主流 Linux 发行版，提供 .deb（适配 Ubuntu/Debian）、.rpm（适配 RHEL/Fedora）以及通用 .tar.gz 格式，并全面支持 x64 与 ARM64 架构。
下载
为什么 load 高但
很低
这是最常被误解的情况。高负载 ≠ 高 CPU 使用率。当大量进程卡在
状态（比如等待慢盘响应、NFS 超时、驱动挂起），它们不消耗 CPU 时间，但会计入 load。此时你会看到：
或
显示 load > 核心数
（空闲率很高）
中
接近 100% 或
异常高
验证方法：
查 D 状态进程：
看当前就绪+不可中断进程数：
第四字段（如
中斜杠前的
）
别只盯着 uptime，下一步该做什么
是第一道筛子，不是终点。它告诉你“有问题”，但不告诉你“哪出问题”。接下来必须分情况跟进：
如果 load 高 + CPU 使用率也高 → 用
按
排序，找
高的进程
如果 load 高 + CPU 使用率低 → 用
查 I/O 延迟，用
找
状态线程
如果 load 值本身不高（如
）但服务变慢 → 可能是单个进程锁竞争、内存换页、网络延迟等，load 不敏感
真正容易被忽略的是：/proc/loadavg 的第四字段（就绪+D态进程实时计数）比 uptime 的三个平均值更及时，适合脚本监控突增；而 15 分钟值是否持续高于核心数，比 1 分钟值冲到 10 更值得干预。
uptimeuptime21:31:45 up 12 days, 7:22, 2 users, load average: 2.45, 1.89, 1.33RD2.451.891.331.33 > 1.89 > 2.452.45 > 1.89 > 1.33load average: 4.1, 3.9, 3.76.2, 6.5, 6.8%Cpu(s)Duptimetop%Cpu(s): 95.7 idiostat -x 1%utilawaitps -eo stat,pid,comm | grep " D "cat /proc/loadavg2/1242uptimetopP%CPUiostat -x 1psD0.3, 0.4, 0.5