阿里云服务器负载状态查询-uptime查询出load average的解释（查询等待 CPU 去处理的任务队列长度）
一、查询
在控制台
输入
uptime
一般显示都是这样
14:35:22 up 28 days, 2:17, 1 user, load average: 1.82, 1.56, 1.21重点看load average后面三个数字：0.26 0.26 0.19
三个数字分别表示：1 分钟负载、5 分钟负载、15 分钟负载
二、原理
Load Average =等待 CPU 去处理的任务队列长度
不是 CPU 使用率百分比！
举个排队例子，例如
CPU 核心 = 窗口办事员 进程任务 = 办业务的人 load average = 队伍总人数
1 核 CPU = 1 个窗口
- load=1：窗口刚好满负荷，没人排队
- load>1：有人排队，处理不过来，任务阻塞
- load=3：窗口前排了 3 个人，严重拥堵
4 核 CPU = 4 个窗口
- load=4：刚好满载
- load=6：4 个人在办，2 个人排队
三、三个数值分别代表什么趋势
第一个值：1 分钟负载瞬时波动，刚发生的峰值。 比如刚打包 Maven、重启 Jar、数据库大批量查询，瞬间拉高。
第二个值：5 分钟负载中期压力，判断是不是持续高负载。
第三个值：15 分钟负载长期基线，看服务器常态压力。
趋势判断口诀
- 1min > 5min >15min：压力正在下降，临时突发峰值，问题不大
- 1min < 5min <15min：压力持续上涨，正在越来越卡，必须排查
- 三个都很高且持平：长期满载，硬件 / 代码瓶颈
四、不同 CPU 核心数警戒线（直接套用）
| CPU 核心数 | 安全值 | 偏高警戒线 | 严重过载 |
|---|---|---|---|
| 1 核 | <0.7 | ≥1.0 | ≥1.5 |
| 2 核 | <1.4 | ≥2.0 | ≥3.0 |
| 4 核 | <2.8 | ≥4.0 | ≥6.0 |
简单粗暴规则：负载数值 ≈ CPU 核心数 = 满载临界点
五、load 高 ≠ CPU 使用率 100%，两种完全不同场景
场景 1：us CPU 高 + load 高（纯 CPU 计算跑满）
top 里%Cpu(s): us 95%原因：
- 若依代码死循环、大量循环递归
- 复杂报表大量运算、大数据量导出
- 频繁 Full GC，Java 疯狂垃圾回收 表现：接口超时、页面加载转圈、GC 日志刷屏
场景 2：wa iowait 高 + load 高，但 CPU 使用率很低（最容易忽略）
top 里%Cpu(s): wa 60%+CPU 没事干，全都在等磁盘读写。 原因：
- MySQL 大量慢查询、无索引全表扫描
- 日志疯狂写入磁盘、nohup.out 超大
- 磁盘 IO 瓶颈、云盘性能差 这就是IO 负载拉高 load，CPU 闲着但系统队列堵死。
六、因为我这是若依项目，所以load 高排查很重要，检查步骤如下
- top 按 P 按 CPU 排序，看第一个是不是
java进程- 如果java 占用过高：看 Jar 日志 GC 情况、是否死循环、导出大数据
- top 看 wa 值是否很高 → 查 MySQL 慢日志、磁盘占用 df -h
- df -h 看磁盘是否接近 100%，磁盘满直接导致 IO 阻塞 load 飙升
- 看是否定时任务在执行：数据库备份、日志切割、代码打包
- 是否爬虫 / CC 攻击疯狂请求 Nginx，压垮后端接口
七、补充一下，还有两个嘿若依混淆的知识点
1. 单核 2 核机器跑若依建议负载底线
1 核 1G 服务器：长期 load 尽量＜0.8，超过就容易接口超时、Redis 连接超时 2 核 2G 服务器：长期 load＜1.6 为宜
2. load 很低但服务器卡？
大概率内存不足，free -h 看到 Swap 被大量使用，物理内存不够频繁交换磁盘，肉眼很卡，但 CPU 队列不长所以 load 不高。
记住：
左升右降 = 压力回落，左降右升 = 压力加重；
us 高是代码耗 CPU，wa 高是磁盘 IO 瓶颈；