最近经常在线上排查一些问题，在大多数情况下，都是代码写的业务逻辑有问题；还有一些情况是内存上导致的问题，如 OOM 或者由于数据量大导致的一些问题；但是很少会关注，但常常又会瞟一眼的，这个关注点就是 CPU。
在说到 CPU 的时候往往除了 top 看一下 CPU 使用率之外，你还会关注别的什么吗？好像也不会。
但是其实当真正出现问题的时候，很多 CPU 相关的指标都会反映出一些问题，经过之前的学习今天就来总结记录一下。
诊断指标
平均负载
定义
系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数（单位时间内活跃进程数）
查看
uptimetop
指标
当平均负载高于 CPU 数量的 70% 可能就有问题了（在实际中如果你看到平均负载突然升高，也就是三个值呈现递减的趋势，就需要考虑 CPU 问题了）
CPU 使用率
定义
除了空闲时间外的其他时间占总 CPU 时间的百分比
查看
toppsmpstat -P ALL 5pidstat
指标
这个其实不用说你就有感觉的，如果你看到你的程序占用了 30%CPU 使用率，而别人都没得用，那就肯定奇怪了
上下文切换
定义
将前一个任务的 CPU 上下文保存起来，然后加载别的任务的上下文并执行
查看
vmstat 5pidstat -wcat /proc/interrupts
指标
上下文切换容易被忽略，很多时候并不会看这个；一般当上下文切换次数超过一万次，或者切换次数出现数量级的增长时，很可能就存在问题了。
如果是自愿上下文切换多，那么考虑 I/O 、内存等资源不够导致；如果是非自愿切换多，那么考虑 CPU 性能瓶颈
排查步骤
看了那么多指标，我想你也肯定头晕，我总不能每次到服务器上想看看有没有问题，就把所有命令全部一股脑敲一遍吧。
首先，我们一般遇到 CPU 的问题比较少，其次我下面从一个开发的视角（运维肯定会更专业），来说下我一般的排查步骤，仅供参考。
- 监控告警，一般大公司或者云厂商都有服务器监控，监控项肯定包含 CPU，如果有肯定是要先看下监控数据
- 看服务器卡不卡，你要是敲个命令响应半天，排除你网络卡的原因，那么多半是服务器要不行了
- 确定当前压力，当前用户访问频繁（本身压力就很大）或者说当前只有几十个用户访问（平峰状态）
- uptime，top 看平均负载和使用率，如果没问题，一般就可以先考虑别的因素了
- 如果确实在没什么用户访问的情况下使用率高，pidstat 看一眼中断，看一眼切换
- 如果认为确实有问题看一眼 ps，看一眼网络，看一眼系统调用，基本就能确定大致问题了
问题原因
那么究其根本肯定是你代码写的有问题~ 很少说服务器 CPU 坏了导致问题吧，至少我是还没见到过。
所以下面列出当 CPU 出现问题时可能的原因（原因有很多，这里列举我曾经见过的）
死循环
这个是最常见的，也是最容易犯的，如果那个地方偷偷给你挖个坑，CPU 立马就搜搜的上去了。
网络请求
大量网络请求导致触发了很多中断，就是常说的小包问题，或者常见的 SYN FLOOD
定时器
很多程序中定时器的使用也会造成 CPU 使用率高，虽然可能只有 3% 这样。常见的情景有：大量的任务执行，每个任务都有一个超时的定时器去跟踪任务的超时。
频繁的错误系统调用
有时可能你看到平均负载高，但是找不到进程。可能由于你执行一个什么命令，但是命令执行失败了，然后不停的重试导致。其中触发的频繁的系统调用，导致上下文切换频繁，从而出现问题。
过多的线程或协程
也曾遇到过创建过多的线程或协程导致切换不过来的情况，并且前面的任务做不完，后面的任务又堆上来，越滚越大。这个容易解决的，只要搞个线程池，限制一下最大基本都能解决。
I/O 操作
绕过缓存，直接读磁盘 I/O，iowait 反映会很明显。现在很多语言都有封装库，所以并不常见。
僵尸进程
进程已经结束，但是父进程没有回收描述符 pid 等资源，一直 wait 下去。现在很多语言也很少有直接操作 fork 的玩法，多数情况下是线程或协程搞定，所以 Z 状态也少见，实际中多看看 D 状态存在时间可能会找到问题关键。
总结
总结一下，可能性比较高的 CPU 问题情况大致可以分为两种：
- 异步任务的不正常处理（访问不频繁但 CPU 高）
- 系统调用或网络请求的不正常处理（频繁请求变得很卡）
以上就是相关 CPU 问题的总结和排查方式，虽然具体情况具体分析，但很多时候遇到具体情况你应该知道怎么分析。
