uptime的三个负载值分别代表1、5、15分钟平均负载，反映不同时间尺度的压力趋势；需结合CPU核心数判断是否过载，并通过iostat、top等工具区分CPU或I/O瓶颈，配合定时日志与绘图分析变化规律。
直接看 uptime 输出的三个数字本身不能判断压力源，只能告诉你“有多忙”；要识别是 CPU、磁盘 I/O 还是其他资源在拖慢系统，必须把负载值放进时间维度里看变化，并和硬件能力对照。
明确三段时延对应的实际含义uptime 末尾的三个浮点数（如 1.23, 0.98, 0.76）不是并列指标，而是不同时间窗口的加权平均：
- 第一个数：过去 1 分钟的平均负载，响应快、波动大，适合捕捉突发任务（如 cron 批量脚本、部署动作）
- 第二个数：过去 5 分钟的平均负载，最常用，能过滤毛刺，反映当前真实承压水平
- 第三个数：过去 15 分钟的平均负载，平滑度高、滞后明显，适合确认问题是否持续存在
这三个值的关系比绝对值更重要。例如：
-
0.45, 0.82, 1.30→ 持续爬升，压力在积累 -
2.15, 1.89, 1.72→ 短期冲高后回落，可能是瞬时行为 -
3.2, 3.1, 3.3→ 长期稳定高位，需立即排查
用定时日志记录负载变化
单次 uptime 是快照，没有趋势价值。必须带时间戳持续采集：
- 推荐每 60 秒执行一次，写入 CSV 文件：
while true; do echo "$(date '+%Y-%m-%d %H:%M:%S'),$(uptime | awk -F'load average:' '{print $2}' | sed 's/ //g')" >> /var/log/load-trend.csv sleep 60 done - 关键细节：
-
awk -F'load average:'比正则更稳，适配不同发行版空格差异 -
sed 's/ //g'清除所有空格，确保 CSV 字段对齐（如1.23,0.98,0.76） - 日志存
/var/log/而非/tmp，避免重启丢失
-
结合 CPU 核心数解读负载数值
负载高低没有固定阈值，必须对标逻辑核数（含超线程）：
- 查逻辑核数：
grep -c 'model name' /proc/cpuinfo - 判断标准：
- 负载 < 核心数：资源有余量
- 负载 ≈ 核心数：满负荷运行，属正常上限
- 负载持续 > 核心数：进程开始排队，响应可能延迟
- 负载远高于核心数（如 4 核机器达 12）：大概率已出现卡顿或超时
注意：load = 3.2 在 4 核机器上不危险，在 2 核机器上就表示平均有 1.2 个任务在等资源。
区分压力来源：负载高 ≠ CPU 忙
大量 D 状态进程（不可中断等待，常见于磁盘 I/O）会显著推高负载，但 top 显示的 %CPU 可能很低：
- 若
iostat -x 1中%util接近 100% 或await持续 > 10ms，说明磁盘瓶颈 - 若
top中%wa（I/O wait）长期 > 5%，也指向 I/O 压力 - 若
%CPU高且负载同步升高，才更可能是 CPU 密集型任务导致
此时 ps aux --sort=-%cpu | head -10 和 ps aux --sort=-%mem | head -10 可辅助定位具体进程。
快速绘图观察趋势
用 gnuplot 直接画出三线折线图，无需安装 Python 或 Grafana：
gnuplot -e "
set xdata time; set timefmt '%Y-%m-%d %H:%M:%S'; set format x '%H:%M';
set xlabel 'Time'; set ylabel 'Load Average';
plot '/var/log/load-trend.csv' using 1:2 with lines title '1-min', \
'' using 1:3 with lines title '5-min', \
'' using 1:4 with lines title '15-min'" 图像中若 1 分钟线持续高于 5 分钟线，说明新压力不断加入；若三条线收敛且平行上扬，说明系统长期过载。
不复杂但容易忽略
