CPU监控需区分利用率（三态占比）与负载（排队进程数），结合分布、状态、时间趋势归因；平均负载超核心数×2表明明显排队，多核不均衡比整体高更危险，内存不足常被误判为CPU瓶颈。
监控和分析 CPU 利用率与负载均衡，核心是区分“用了多少”和“排了多长队”，再结合进程分布、状态构成和时间趋势做归因。不是单看一个数字高不高，而是看它为什么高、高得合不合理、是否可持续。
CPU 利用率：盯住三类比例与时间维度
Linux 中的 CPU 利用率不是单一值，而是多个状态时间占比的组合：
- 用户态（%us）：应用程序自身逻辑消耗，比如数据计算、加解密、循环处理。若持续 >60%，需检查代码算法或并发任务量
- 内核态（%sy）：系统调用、中断处理、内存管理等开销。若 %sy 明显高于 %us（如 40% vs 15%），常见于频繁文件读写、网络收发、锁竞争或驱动问题
- I/O 等待（%wa）：CPU 空闲但等待磁盘响应。此时整体利用率可能不高（如 20%），但系统卡顿——本质是 I/O 瓶颈，不是 CPU 不够
建议用 top -d 1 或 mpstat -P ALL 1 每秒刷新观察波动；重点关注连续 5 分钟以上稳定高于 70% 的核心，而非瞬时峰值。
平均负载（Load Average）：判断排队压力是否真实
平均负载反映的是“正在运行 + 不可中断等待”的平均进程数，和 CPU 核心数直接对标：
- load1 > CPU 逻辑核心数 × 1 → 负载已偏重，需关注
- load1 > CPU 逻辑核心数 × 2 → 进程明显排队，响应延迟上升
- 若 load 高但 %us/%sy 很低，大概率是大量 D 状态进程（如磁盘卡死、NFS 挂起）
用 uptime 或 cat /proc/loadavg 查看三值；配合 ps -eo stat,pid,comm | grep "D " 找不可中断进程，定位根因。
负载均衡表现：查分布、查迁移、查亲和性
多核系统下，不均衡比整体高更危险——部分核跑满、其余空闲，说明调度或应用设计有问题：
- 用
mpstat -P ALL 1观察各核心 %idle 是否差异过大（如一个 core idle=5%，另三个 idle=85%） - 用
pidstat -t -p [PID] 1看线程在哪些 CPU 上运行，是否存在单线程绑定某核长期占满 - 检查是否误设了
taskset或容器cpuset，人为限制了调度范围 - Java 应用注意 GC 线程是否集中触发，Python 注意 GIL 导致多线程无法并行利用多核
内存协同分析：避免误判 CPU 瓶颈
CPU 表现异常常由内存间接引发：
- 内存不足 → 频繁 swap → 大量 page-in/out → 内核态飙升 + %wa 上升 → 看似 CPU 问题，实为内存瓶颈
- 用
free -h看可用内存是否持续 vmstat 1 中看si/so（swap in/out）是否非零 - 用
slabtop或cat /proc/meminfo | grep SReclaimable查内核缓存是否过度占用（如 dentry/inode 泄漏） - Java 程序注意堆外内存（Netty direct buffer、JNA）不计入 JVM 堆，但会吃系统内存
