平均负载需结合趋势、归一化和构成分析：用watch -d uptime观察动态变化，脚本定期采集并对比历史数据，按CPU核心数归一化判断阈值，再通过vmstat区分CPU或I/O瓶颈。
直接看平均负载趋势，关键不是单次数值，而是连续观察它随时间的变化规律。重点不在“怎么取数”，而在“怎么看出趋势”。
用 watch -d uptime 动态盯住变化
这是最轻量、最直观的方式：
- 运行 watch -d uptime，每2秒刷新一次，-d 参数会高亮标出变动的数字（比如1分钟负载突然跳升）
- 盯着三个值（1/5/15分钟）的相对关系：如果 1分钟 > 5分钟 > 15分钟，说明负载正在爬升；反过来则在回落
- 适合应急排查——刚收到告警时，先敲这条命令，30秒内就能判断是突发抖动还是持续恶化
用脚本定期采集并记录历史数据
要看出小时级或天级趋势，必须存下来对比：
- 用 uptime | awk '{print $NF}' 提取15分钟负载值（最能反映稳定状态）
- 配合 date +'%F %T' 打上时间戳，每5分钟追加一行到日志文件
- 后续可用 awk '{print $1,$2,$NF}' load.log | column -t 整齐查看，或导入 Excel 画折线图
结合 CPU 核心数做归一化判断
负载绝对值没意义，必须和硬件能力对照着看：
- 查逻辑 CPU 总数：grep -c 'model name' /proc/cpuinfo
- 计算每核平均负载：uptime | awk '{print $NF}' | xargs -I{} echo "scale=2; {}/$(grep -c 'model name' /proc/cpuinfo)" | bc
- 经验参考：每核负载长期超过 0.7 就该关注；超过 1.0 表示有进程排队等 CPU；超过 3.0 很可能已影响服务响应
搭配 vmstat 看清负载构成
平均负载高不等于 CPU 忙——可能是 I/O 卡住进程在等磁盘：
- 运行 vmstat 5（每5秒刷新），重点关注 r（运行队列长度）和 b（不可中断睡眠进程数）
- 如果 r 值持续大于 CPU 核数，说明 CPU 真瓶颈；如果 b 明显升高，大概率是磁盘或网络设备拖慢了进程
- 这时再查 iostat -x 5 或 iotop，就能定位到底是哪块盘在拖后腿
