4. CPU负载分析基础：CPU利用率、负载平均值、上下文切换、中断频率
说到CPU负载分析，很多工程师第一反应就是看CPU利用率。但说实话，光看利用率远远不够。我在项目中踩过不少坑，有时候利用率才60%，系统却卡得不行。后来才明白，CPU负载分析是个系统工程，得把利用率、负载平均值、上下文切换、中断频率这几个指标串起来看。
这一章，我就带你把这四个核心指标彻底搞明白。每个指标怎么算、怎么看、怎么用，我都会结合实战经验来讲。
4.1 CPU利用率：最直观但最容易误读的指标
CPU利用率，说白了就是CPU干活的时间占比。但这里有个关键问题——它分好几种类型。
| 利用率类型 | 含义 | 典型场景 |
|---|---|---|
| 用户态 (user) | 应用程序代码执行时间占比 | 算法计算、业务逻辑处理 |
| 内核态 (system) | 系统调用、内核服务执行时间占比 | 文件读写、网络收发、内存管理 |
| 软中断 (softirq) | 内核软中断处理时间占比 | 网络数据包处理、定时器回调 |
| 硬中断 (hardirq) | 硬件中断处理时间占比 | 外设响应、DMA完成通知 |
| I/O等待 (iowait) | CPU等待I/O完成的时间占比 | 磁盘读写、网络I/O阻塞 |
| 空闲 (idle) | CPU空闲时间占比 | 系统无任务可执行 |
关键认知：CPU利用率高不一定代表系统有问题，关键要看是哪类利用率高。用户态高说明应用在忙，内核态高说明系统调用频繁，iowait高说明I/O是瓶颈。
我在一个工业控制项目中遇到过这样的情况：CPU利用率只有45%，但系统响应却时快时慢。一查才发现，iowait占了30%。说白了，CPU大部分时间都在等磁盘，根本没真正干活。
4.2 负载平均值：系统压力的真实写照
负载平均值（Load Average）这个指标，很多新手容易和CPU利用率搞混。我刚开始做嵌入式时也犯过这个错。
负载平均值表示的是系统中处于运行状态和不可中断睡眠状态的进程平均数量。它反映的是系统整体的"拥挤程度"。
我的经验：在单核系统上，负载平均值超过1.0就说明系统已经过载了。多核系统可以按核数换算，比如4核系统负载超过4.0才算过载。但实际项目中，我建议负载平均值不要超过核数的70%。
Linux下用top或uptime命令可以看到三个负载平均值：1分钟、5分钟、15分钟的平均值。
# 查看系统负载
$ uptime
10:30:45 up 3 days, 2:15, 2 users, load average: 0.85, 0.92, 0.78
# 使用top命令
$ top -n 1 | grep "load average"
top - 10:30:45 up 3 days, 2:15, 2 users, load average: 0.85, 0.92, 0.78这三个数值怎么解读？我一般这样看：
- 1分钟负载 > 15分钟负载：系统压力正在上升，需要关注
- 1分钟负载 < 15分钟负载：系统压力正在缓解
- 三个值都很高且接近：系统持续过载，需要优化
- 负载高但CPU利用率低：大概率是I/O瓶颈，进程在等I/O
注意：负载平均值和CPU利用率不是一回事。负载高但利用率低，说明很多进程在等待资源（通常是I/O）。负载低但利用率高，说明CPU在高效工作，没有浪费。
4.3 上下文切换：看不见的性能杀手
上下文切换，就是CPU从一个进程/线程切换到另一个。每次切换都要保存当前状态、加载新状态，这本身就有开销。
我曾经在一个实时控制项目中，发现系统偶尔会出现毫秒级的响应延迟。查了半天，最后发现是上下文切换太频繁了——每秒超过10万次。每次切换虽然只有几微秒，但累积起来就造成了明显的抖动。
查看上下文切换频率的方法：
# 使用vmstat查看上下文切换
$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 0 256780 12340 456780 0 0 12 34 456 1234 12 8 78 2 0
1 0 0 256780 12340 456780 0 0 10 28 432 1189 11 7 80 2 0
# cs列就是每秒上下文切换次数（context switches per second）上下文切换频率多少算正常？我给出一个参考范围：
| 系统类型 | 正常范围 | 需要关注 | 需要优化 |
|---|---|---|---|
| 低负载嵌入式系统 | < 1000次/秒 | 1000-5000次/秒 | > 5000次/秒 |
| 中等负载系统 | < 5000次/秒 | 5000-20000次/秒 | > 20000次/秒 |
| 高负载服务器 | < 20000次/秒 | 20000-50000次/秒 | > 50000次/秒 |
降低上下文切换的技巧：
- 减少线程数量，用线程池复用线程
- 使用异步I/O代替同步阻塞I/O
- 调整进程/线程的调度策略和优先级
- 合并小任务，减少任务切换频率
4.4 中断频率：外设的"敲门"节奏
中断是外设通知CPU的方式。中断频率太高，CPU大部分时间都在处理中断，真正干活的时间就少了。这就是所谓的"中断风暴"。
查看中断频率的方法：
# 查看中断统计
$ cat /proc/interrupts
CPU0 CPU1
16: 1234567 2345678 IO-APIC 2-edge timer
17: 12345 23456 IO-APIC 17-fasteoi eth0
18: 123 234 IO-APIC 18-fasteoi mmc0
# 使用mpstat查看中断率
$ mpstat -I CPU 1
CPU intr/s
all 4567
0 2345
1 2222中断频率高不一定都是坏事。关键要看中断处理时间。如果每个中断处理很快（微秒级），频率高一点也没关系。但如果中断处理慢，或者中断处理中做了太多事情，就会严重影响系统性能。
中断优化的核心原则：中断处理程序只做最紧急的事情（比如读取数据、清除中断标志），耗时的处理放到下半部（tasklet、工作队列）或用户态去做。
我在一个网络设备项目中遇到过中断频率过高的问题。千兆网卡每秒产生超过10万次中断，CPU利用率中硬中断占了40%。后来启用了NAPI（New API）和中断合并（Interrupt Coalescing），中断频率降到了每秒5000次左右，CPU利用率硬中断部分降到了5%以下。
4.5 四个指标的关系与综合分析
这四个指标不是孤立的，它们之间有着密切的关系。我画了一张图来展示它们之间的关联：
实际分析时，我一般按这个步骤来：
- 先看负载平均值：判断系统整体压力是否过大
- 再看CPU利用率分布：定位是CPU忙、I/O等还是中断多
- 检查上下文切换：如果利用率不高但负载高，大概率是上下文切换太频繁
- 排查中断频率：如果硬中断占比高，检查外设中断是否合理
实战案例：一个数据采集系统，CPU利用率只有30%，但数据采集经常丢包。分析发现：
- 负载平均值：2.5（双核系统，已经过载）
- CPU利用率：user 20%, system 8%, iowait 2%
- 上下文切换：45000次/秒（过高）
- 中断频率：12000次/秒（网卡中断）
根因：网卡中断太频繁，导致大量上下文切换，虽然CPU看起来不忙，但有效工作时间被切碎了。优化方案：启用中断合并，使用NAPI，将中断频率降到2000次/秒，上下文切换降到5000次/秒，问题解决。
4.6 常用分析工具速查
| 工具 | 查看指标 | 常用命令 |
|---|---|---|
| top | CPU利用率、负载、进程状态 | top -d 1 |
| vmstat | 上下文切换、中断、CPU利用率 | vmstat 1 5 |
| mpstat | 每核CPU利用率、中断率 | mpstat -P ALL 1 |
| pidstat | 进程级CPU利用率、上下文切换 | pidstat -w -u 1 |
| /proc/stat | 系统级CPU统计 | cat /proc/stat | grep cpu |
| /proc/interrupts | 中断分布统计 | cat /proc/interrupts |
我的习惯：在嵌入式系统上，我通常先用vmstat 1快速扫一眼，如果发现异常再用pidstat和/proc/interrupts深入排查。不要一上来就用复杂工具，先看大方向。
嗯，CPU负载分析这块，说白了就是四个指标互相印证。光看一个指标很容易误判。我见过太多工程师看到CPU利用率低就觉得系统没问题，结果负载已经高得离谱了。记住：利用率是"多忙"，负载是"多挤"，上下文切换是"多乱"，中断是"多吵"。把这四个维度结合起来，你就能准确判断系统的真实状态。