最近经常在线上排查一些问题,在大多数情况下,都是代码写的业务逻辑有问题;还有一些情况是内存上导致的问题,如 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 问题的总结和排查方式,虽然具体情况具体分析,但很多时候遇到具体情况你应该知道怎么分析。