直接看us（用户态）和sy（内核态）占比可快速判断cpu时间去向：us高说明程序逻辑耗时多，sy高说明系统调用或内核工作繁重；us+sy持续超85%表明cpu负载偏高，需结合pidstat、vmstat进一步定位进程级或系统级瓶颈。
直接看 us（用户态）和 sy（内核态）这两项占比，就能快速判断 CPU 时间主要花在哪——不是在跑你的程序，就是在替你的程序干活。
用 top 命令看整体分布
运行 top，观察第三行 %Cpu(s) 后的字段：
- us：用户空间代码占用的 CPU 时间，比如你的 Python 脚本、Java 应用、数据库查询逻辑；
-
sy：内核空间执行的时间，比如系统调用处理（
read/write）、进程调度、内存管理、中断响应； - 注意：
ni是调整过 nice 值的用户态时间，也属于用户态范畴；wa不是 CPU 真正工作的时间，而是“干等着 I/O”，不算进 us/sy； - 如果
us + sy持续超过 85%，说明 CPU 负载偏高，需进一步定位是哪类任务主导。
用 pidstat 查单个进程的细分消耗
top 只给全局视图，pidstat -u 1 3 才能看清每个进程的用户态和内核态拆分：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- %usr：该进程在用户态运行的 CPU 百分比；
- %system：该进程触发的系统调用在内核态消耗的 CPU 百分比；
- 例如一个进程
%usr很低但%system很高，大概率在频繁做小量读写（如日志刷盘、短连接 accept）、或陷入锁竞争/上下文切换； - 加
-t参数还能看到线程级的 us/sy 分布，对多线程程序排查很有用。
用 vmstat 辅助判断系统行为特征
运行 vmstat 2 5，重点关注这几列：
- us 和 sy：和 top 一致，但更稳定，适合观察趋势；
-
cs（context switch）：每秒上下文切换次数。若
sy高且cs也明显偏高，可能是大量进程/线程争抢 CPU 或频繁系统调用； -
in（interrupts）：每秒中断次数。若
sy高而in也飙升，需检查硬件中断是否异常（如网卡软中断堆积、磁盘响应延迟）； -
r（run queue）：就绪但没轮到 CPU 的进程数。若
r > CPU 核数且us/sy都高，说明 CPU 确实成了瓶颈。
结合场景快速定性问题
不用死记数字，对照典型模式能加快判断：
- us 显著偏高（>70%），sy 正常（：应用逻辑密集计算，比如图像处理、加密解密、未优化的循环；
- sy 显著偏高（>30%），us 中等：常见于高频小包网络服务（Nginx/Redis）、大量 fork/vfork、或内核模块存在效率问题；
- us 和 sy 都低，但 wa 高：CPU 其实不忙，只是被 I/O 卡住，此时看 us/sy 没意义，应转查磁盘或网络；
- sy 高 + cs 高 + r 高：大概率是锁竞争（如 futex_wait）、或线程数远超 CPU 核数导致调度开销暴涨。
