tload是最轻量开箱即用的终端图形化工具，用于快速显示1分钟平均负载的实时折线图；需终端宽度≥80列，支持-d设刷新间隔、-t加时间刻度、-s调字符醒目度，但仅读/proc/loadavg首字段且不保存数据。
用 tload 快速看实时负载曲线
tload 是最轻量、开箱即用的终端图形化工具，适合快速确认当前负载是否在抖动或爬升。它不依赖 GUI，也不需要写脚本，直接画出近似折线图。
常见错误现象：运行 tload 后画面空白或只显示横线——通常是因为终端宽度太窄（tload 需要至少 80 列），或当前负载长期接近 0（比如 load average: 0.00, 0.00, 0.00），导致所有点都压在底线上。
- 默认每秒刷新一次，可用
tload -d 2改为 2 秒间隔，减少终端干扰 - 加
-t显示时间刻度，方便肉眼判断持续时长；加-s #换成#字符更醒目 - 它只读
/proc/loadavg的第一个字段（1 分钟负载），所以看到的是瞬时趋势，不是历史回溯 - 注意：
tload不能保存图像，退出即丢数据；也不支持多线（无法同时画 1/5/15 分钟）
用 shell + uptime 定时采集 CSV 日志
单次 uptime 输出只有快照，要看出波动必须带时间戳持续记录。最稳的方式是绕过正则，用字段分隔符提取，避免不同发行版空格数量不一致导致解析失败。
容易踩的坑：$(uptime | awk '{print ,,}') 这种写法在 Ubuntu 和 CentOS 上字段位置可能差 1 位；而 awk -F'load average:' 始终锚定关键词，兼容性高。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 推荐写法：
echo "$(date '+%Y-%m-%d %H:%M:%S'),$(uptime | awk -F'load average:' '{print $2}' | sed 's/ //g')" >> /var/log/load-trend.csv - 日志路径必须用
/var/log/，不能写/tmp/——重启后丢失，趋势就断了 -
sleep 60是合理下限；设成sleep 10没意义，因为 1 分钟负载本身就是指数衰减平均值，高频采样只是重复同一统计口径 - 确保
/var/log/load-trend.csv有写权限，建议用sudo tee或提前chown所属用户
用 gnuplot 画三线趋势图
gnuplot 不需要 Python 环境，几行命令就能把 CSV 转成可读折线图，关键是三条线（1/5/15 分钟）叠加能一眼看出斜率差异。
典型错误：图中纵轴数值看起来很高，但没结合 CPU 核心数解读——比如负载 4.2 在 8 核机器上完全正常，在 2 核机器上就已排队。
- 查逻辑核数用
grep -c 'model name' /proc/cpuinfo，不是物理核数，也不是nproc（后者可能受 cgroup 限制） -
gnuplot命令里using 1:2表示第一列（时间）和第二列（1 分钟负载），using 1:3是第三列（5 分钟），以此类推 - 若 CSV 文件头没加字段名，
gnuplot默认从第一行开始读；如有标题行，需加skip 1 - 生成的图是 PNG 或 PDF，但命令本身不指定输出格式——得加
set terminal png和set output 'load.png'才能保存
为什么 vmstat 1 比 top 更适合定位负载来源
top 显示的 load average 和 uptime 一样，只是快照；而 vmstat 1 每秒输出一行底层调度指标，能验证负载升高到底卡在哪一层。
关键信号：如果 load average 高但 %Cpu(s) 里 id（idle）还剩 60% 以上，大概率不是 CPU 瓶颈——这时候 vmstat 的 b（blocked 进程数）和 wa（I/O wait %）才是重点。
-
b列持续 > 0，说明有进程卡在不可中断睡眠（D 状态），基本锁定 I/O 问题 -
wa> 30%，再配合iostat -x 1看%util是否接近 100% 或await异常升高 -
r列（就绪进程数）长期大于逻辑核数，才说明真正在争 CPU；否则别急着 kill 进程 -
vmstat第一行是系统启动以来的平均值，忽略它；从第二行开始才是每秒实时值
/proc/loadavg 第五个字段（当前运行队列长度）和 ps r | wc -l 对比——如果后者远小于前者，说明大量进程堵在 D 状态，此时画出来的“CPU 负载图”其实反映的是磁盘响应延迟。 
