负载值反映单位时间平均活跃进程数（R/D状态），非CPU使用率；需先用nproc或grep -c 'processor' /proc/cpuinfo确认逻辑CPU数，再结合15分钟load是否持续超1.5倍逻辑CPU数判断真实压力。
负载值本身不是CPU使用率，而是单位时间里平均有多少进程在“活”着等资源——包括正在跑的（R状态）和卡在磁盘I/O里的（D状态）。所以看到 load average: 8.2, 7.5, 6.9，第一反应不该是“CPU爆了”，而该先查：你这台机器到底有几个逻辑CPU？
怎么看当前系统的逻辑CPU数？
这是所有判断的前提。别凭“8核16线程”这种宣传参数猜，Linux里只认实际暴露给内核的线程数：
- 最简方式：
nproc—— 直接输出数字，比如16 - 更底层验证：
grep -c 'processor' /proc/cpuinfo—— 和nproc结果应一致 - 想看详细拓扑（比如是否启用了超线程）：
lscpu | grep -E "(CPU\(s\)|Thread|Core|Socket)"
⚠️ 容易踩的坑：有人用 grep -c 'model name' /proc/cpuinfo，这在某些虚拟化环境（如KVM未透传CPU topology时）会少算；nproc 更可靠。
三个load值（1/5/15分钟）到底该盯哪个？
重点看后两个——5分钟 和 15分钟 平均值。它们平滑了瞬时毛刺，反映的是系统是否持续承压：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
-
1分钟值突高（如 12.0），但5/15分钟仍低（0.3, 0.2）→ 短时任务爆发，比如某脚本批量解压、crontab刚触发一个重活，不用急着干预 -
15分钟值 > 逻辑CPU数 × 1.5且没回落 → 真正的风险信号，说明排队已成常态 - 若
1分钟 < 1，但5/15分钟 > 4（假设是4核）→ 负载其实在退潮，系统正恢复，别误判为恶化
load高 ≠ CPU忙，怎么快速定位真凶？
很多情况下，top 显示 %us（用户态CPU）才5%，%wa（iowait）却飙到70%，而 load average 已经破10——这就是典型的I/O拖累。此时CPU空闲，但进程卡在D状态等磁盘响应：
- 查D状态进程：
ps aux | awk '$8 ~ /D/ {print}'—— 输出越多，越可能是存储或驱动问题 - 查磁盘压力：
iostat -x 1 3，重点关注：%util > 90%（设备饱和）、await > 50ms（单次IO等待太久）、r/s + w/s是否远超磁盘标称IOPS - 对比验证：
vmstat 1 5中看procs下的r（就绪队列长度）是否长期 > 逻辑CPU数，同时bi/bo（块输入/输出）很高 → 队列+IO双高，基本坐实I/O瓶颈
什么时候该动手，什么时候可再等等？
判断阈值必须绑定你的硬件能力：
- 逻辑CPU数 = 8 →
load > 12（即 1.5×8）且15分钟值稳定在高位 → 建议立即查服务日志、慢查询、异常定时任务 - 逻辑CPU数 = 2 →
load = 1.8持续15分钟 → 其实已接近临界，尤其对数据库或Web服务这类延迟敏感型应用 - 虚拟机环境要额外小心：
load高但宿主机cpu steal time (%st)也高 → 是被隔壁虚机抢资源了，不是你自己的锅
最常被忽略的一点：负载是“活跃进程”的平均数，不是“CPU使用率”。一个Java应用堆内存打满引发频繁GC，会导致大量线程卡在 D 或 R 状态，load 会飙升，但 top 的CPU%可能不显眼——这时候光看CPU%会彻底错过根因。
