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