uptime末尾三个数字是1/5/15分钟系统负载平均值，表示单位时间内处于r或d状态的进程平均数量，需结合cpu核心数判断是否异常：4核机器load达8.2、7.5、6.9即持续超载。

直接看 uptime 就能知道负载是否异常

不用打开一堆工具，uptime 一行输出就包含最关键的三个负载值：1分钟、5分钟、15分钟平均负载。它不告诉你哪个进程在作怪，但能立刻判断“要不要马上动手”。如果 load average: 8.2, 7.5, 6.9 出现在一台 4 核 CPU 的机器上，说明系统已持续超载——因为理想上限是逻辑核心数（不是物理核数），查法：grep 'model name' /proc/cpuinfo | wc -l。

top 里看实时负载 + CPU 状态分布

top 启动后第一行和 uptime 一样显示负载，第三行才是重点：us（用户态）、sy（内核态）、wa（I/O 等待）、id（空闲）这些百分比加起来接近 100% 才可信。常见误判点：

• wa 高但 id 也高？说明 CPU 没瓶颈，真正卡在磁盘或网络响应上
• us 持续 >80% 且 id P 排序找 top 进程
• 按 1 键可展开多核视图，避免把单核打满当成整体负载高

用 vmstat 1 看上下文切换和阻塞源头

vmstat 1 每秒刷新一次，比 top 更适合观察波动。重点关注三列：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• cs（context switch）：每秒上下文切换次数，>10w 往往意味着大量短生命周期进程或线程争抢 CPU
• in（interrupts）：中断频率，异常升高可能指向硬件问题（如网卡、磁盘故障）
• wa 和 r（runnable 进程数）：如果 r 长期 > 逻辑核心数，而 wa 也高，基本锁定是 I/O 设备拖慢了整个调度队列

别只盯着 load average，cat /proc/loadavg 多出的两个字段很关键

cat /proc/loadavg 输出形如 2.45 2.11 1.98 3/512 12345，最后两个数常被忽略：

• 3/512：当前运行队列中活跃进程数 / 总进程数。若第一个数远大于逻辑核心数（比如 16/512 在 4 核机器上），说明大量进程在排队等 CPU
• 12345：最近创建的进程 PID，结合 ps -p 12345 -o pid,tid,comm,etime 可快速定位突发负载来源

真正难缠的问题往往藏在这两个字段里——比如一个 fork 炸弹刚启动时，load average 还没拉高，但 r 值和 /proc/loadavg 第二段已经飙升。