最近经常在线上排查一些问题，在大多数情况下，都是代码写的业务逻辑有问题；还有一些情况是内存上导致的问题，如 OOM 或者由于数据量大导致的一些问题；但是很少会关注，但常常又会瞟一眼的，这个关注点就是 CPU。

在说到 CPU 的时候往往除了 top 看一下 CPU 使用率之外，你还会关注别的什么吗？好像也不会。

但是其实当真正出现问题的时候，很多 CPU 相关的指标都会反映出一些问题，经过之前的学习今天就来总结记录一下。

诊断指标

平均负载

定义

系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数（单位时间内活跃进程数）

查看

  • uptime
  • top

指标

当平均负载高于 CPU 数量的 70% 可能就有问题了（在实际中如果你看到平均负载突然升高，也就是三个值呈现递减的趋势，就需要考虑 CPU 问题了）

CPU 使用率

定义

除了空闲时间外的其他时间占总 CPU 时间的百分比

查看

  • top

  • ps

  • mpstat -P ALL 5

  • pidstat

指标

这个其实不用说你就有感觉的，如果你看到你的程序占用了 30%CPU 使用率，而别人都没得用，那就肯定奇怪了

上下文切换

定义

将前一个任务的 CPU 上下文保存起来，然后加载别的任务的上下文并执行

查看

  • vmstat 5
  • pidstat -w
  • cat /proc/interrupts

指标

上下文切换容易被忽略，很多时候并不会看这个；一般当上下文切换次数超过一万次，或者切换次数出现数量级的增长时，很可能就存在问题了。

如果是自愿上下文切换多，那么考虑 I/O 、内存等资源不够导致；如果是非自愿切换多，那么考虑 CPU 性能瓶颈

排查步骤

看了那么多指标，我想你也肯定头晕，我总不能每次到服务器上想看看有没有问题，就把所有命令全部一股脑敲一遍吧。

首先，我们一般遇到 CPU 的问题比较少，其次我下面从一个开发的视角（运维肯定会更专业），来说下我一般的排查步骤，仅供参考。

  1. 监控告警，一般大公司或者云厂商都有服务器监控，监控项肯定包含 CPU，如果有肯定是要先看下监控数据

  2. 看服务器卡不卡，你要是敲个命令响应半天，排除你网络卡的原因，那么多半是服务器要不行了

  3. 确定当前压力，当前用户访问频繁（本身压力就很大）或者说当前只有几十个用户访问（平峰状态）

  4. uptime，top 看平均负载和使用率，如果没问题，一般就可以先考虑别的因素了

  5. 如果确实在没什么用户访问的情况下使用率高，pidstat 看一眼中断，看一眼切换

  6. 如果认为确实有问题看一眼 ps，看一眼网络，看一眼系统调用，基本就能确定大致问题了

问题原因

那么究其根本肯定是你代码写的有问题~ 很少说服务器 CPU 坏了导致问题吧，至少我是还没见到过。

所以下面列出当 CPU 出现问题时可能的原因（原因有很多，这里列举我曾经见过的）

死循环

这个是最常见的，也是最容易犯的，如果那个地方偷偷给你挖个坑，CPU 立马就搜搜的上去了。

网络请求

大量网络请求导致触发了很多中断，就是常说的小包问题，或者常见的 SYN FLOOD

定时器

很多程序中定时器的使用也会造成 CPU 使用率高，虽然可能只有 3% 这样。常见的情景有：大量的任务执行，每个任务都有一个超时的定时器去跟踪任务的超时。

频繁的错误系统调用

有时可能你看到平均负载高，但是找不到进程。可能由于你执行一个什么命令，但是命令执行失败了，然后不停的重试导致。其中触发的频繁的系统调用，导致上下文切换频繁，从而出现问题。

过多的线程或协程

也曾遇到过创建过多的线程或协程导致切换不过来的情况，并且前面的任务做不完，后面的任务又堆上来，越滚越大。这个容易解决的，只要搞个线程池，限制一下最大基本都能解决。

I/O 操作

绕过缓存，直接读磁盘 I/O，iowait 反映会很明显。现在很多语言都有封装库，所以并不常见。

僵尸进程

进程已经结束，但是父进程没有回收描述符 pid 等资源，一直 wait 下去。现在很多语言也很少有直接操作 fork 的玩法，多数情况下是线程或协程搞定，所以 Z 状态也少见，实际中多看看 D 状态存在时间可能会找到问题关键。

总结

总结一下，可能性比较高的 CPU 问题情况大致可以分为两种：

  • 异步任务的不正常处理（访问不频繁但 CPU 高）
  • 系统调用或网络请求的不正常处理（频繁请求变得很卡）

以上就是相关 CPU 问题的总结和排查方式，虽然具体情况具体分析，但很多时候遇到具体情况你应该知道怎么分析。