某个应用的CPU使用率居然达到100%，该怎么办？

本文是通过学习倪朋飞的专栏《Linux性能优化实战》05 | 基础篇：某个应用的CPU使用率居然达到100%，我该怎么办

CPU 使用率

Linux 作为一个多任务操作系统，将每个 CPU 的时间划分为很短的时间片，再通过调度器轮流分配给各个任务使用，因此造成多任务同时运行的错觉。

为了维护 CPU 时间，Linux 通过事先定义的节拍率(内核中表示为 HZ)，触发时间中 断，并使用全局变量 Jiffies 记录了开机以来的节拍数。每发生一次时间中断，Jiffies 的值 就加 1。

节拍率 HZ 是内核的可配选项，可以设置为 100、250、1000 等。不同的系统可能设置不同数值，可以通过查询 /boot/config 内核选项来查看它的配置值。

因为节拍率 HZ 是内核选项，所以用户空间程序并不能直接访问。为了方便用户空间程序，内核还提供了一个用户空间节拍率 USER_HZ，它总是固定为 100，也就是 1/100 秒。这样，用户空间程序并不需要关心内核中HZ被设置成了多少，因为它看到的总是固定值 USER_HZ。

Linux 通过 /proc 虚拟文件系统，向用户空间提供了系统内部状态的信息，而 /proc/stat 提供的就是系统的 CPU 和任务统计信息。比方说，如果我们只关注 CPU 的话，可以执行下面的命令:

# 只保留各个 CPU 的数据
[root@service]# cat /proc/stat |grep ^cpu
cpu     814542002 202895 463561675   1904430351  209834   46885800   192771569  0  0  0
cpu0    200426767 18103  130064086   405382463   58345    15998361   101337973  0  0  0
cpu1    201309739 84968  103182994   545114252   47641    7541473    884379     0  0  0
cpu2    209547634 20138  127524273   409858332   54620    15556994   89808218   0  0  0
cpu3    203257860 79685  102790321   544075303   49227    7788970    740997     0  0  0

这里的输出结果是一个表格。其中，第一列表示的是 CPU 编号，如 cpu0、cpu1 ，而第 一行没有编号的 cpu ，表示的是所有 CPU 的累加。其他列则表示不同场景下 CPU 的累加 节拍数，它的单位是 USER_HZ，也就是 10 ms(1/100 秒)，所以这其实就是不同场景 下的 CPU 时间。

当然，这里每一列的顺序并不需要背下来。只要记住，有需要的时候，查询 man proc 就可以。不过，你要清楚 man proc 文档里每一列的涵义，它们都是 CPU 使用率相关的重要指标，你还会在很多其他的性能工具中看到它们。下面，我来依次解读一下。

man proc

• user(通常缩写为 us)，代表用户态 CPU 时间。注意，它不包括下面的 nice 时间，但 包括了 guest 时间。
• nice(通常缩写为 ni)，代表低优先级用户态 CPU 时间，也就是进程的 nice 值被调整 为 1-19 之间时的 CPU 时间。这里注意，nice 可取值范围是 -20 到 19，数值越大，优 先级反而越低。
• system(通常缩写为 sys)，代表内核态 CPU 时间。
• idle(通常缩写为 id)，代表空闲时间。注意，它不包括等待 I/O 的时间(iowait)。
• iowait(通常缩写为 wa)，代表等待 I/O 的 CPU 时间。
• irq(通常缩写为 hi)，代表处理硬中断的 CPU 时间。
• softirq(通常缩写为 si)，代表处理软中断的 CPU 时间。
• steal(通常缩写为 st)，代表当系统运行在虚拟机中的时候，被其他虚拟机占用的 CPU 时间。
• guest(通常缩写为 guest)，代表通过虚拟化运行其他操作系统的时间，也就是运行虚 拟机的 CPU 时间。
• guest_nice(通常缩写为 gnice)，代表以低优先级运行虚拟机的时间。

通常所说的 CPU 使用率，就是除了空闲时间外的其他时间占总 CPU 时间的百分比，用公式来表示就是:

根据这个公式，我们就可以从 /proc/stat 中的数据，很容易地计算出 CPU 使用率。当然，也可以用每一个场景的 CPU 时间，除以总的 CPU 时间，计算出每个场景的 CPU 使用率。

不过先不要着急计算，我们能确定直接用 /proc/stat 的数据，算的是什么时间段的 CPU 使用率吗?
实际上，这是开机以来的节拍数累加值，所以直接算出来的，是开机以来的平均 CPU 使用率，一般没啥参考价值。

事实上，为了计算 CPU 使用率，性能工具一般都会取间隔一段时间(比如 3 秒)的两次 值，作差后，再计算出这段时间内的平均 CPU 使用率，即

这个公式，就是我们用各种性能工具所看到的 CPU 使用率的实际计算方法。

现在，我们知道了系统 CPU 使用率的计算方法，那进程的呢？跟系统的指标类似，Linux 也给每个进程提供了运行情况的统计信息，也就是 /proc/[pid]/stat。不过，这个文件包含的数据就比较丰富了，总共有 52 列的数据。但是我们不需要掌握每一列的含义，需要的时候，查man proc就行。

回过头来看，是不是说要查看 CPU 使用率，就必须先读取 /proc/stat 和 /proc/[pid]/stat 这两个文件，然后再按照上面的公式计算出来呢?

当然不是，各种各样的性能分析工具已经帮我们计算好了。不过要注意的是，性能分析工具给出的都是间隔一段时间的平均 CPU 使用率，所以要注意间隔时间的设置，特别是用多个工具对比分析时，你一定要保证它们用的是相同的间隔时间。

比如，对比一下 top 和 ps 这两个工具报告的 CPU 使用率，默认的结果很可能不一样，因为 top 默认使用 3 秒时间间隔，而 ps 使用的却是进程的整个生命周期。

怎么查看CPU使用率

知道了 CPU 使用率的含义后，我们再来看看要怎么查看 CPU 使用率。说到查看 CPU 使 用率的工具，我猜你第一反应肯定是 top 和 ps。的确，top 和 ps 是最常用的性能分析工 具:

• top 显示了系统总体的 CPU 和内存使用情况，以及各个进程的资源使用情况
• ps 则只显示了每个进程的资源使用情况。

例如top的输出格式为：

top
top - 11:18:09 up 101 days, 15:50,  1 user,  load average: 0.18, 0.21, 0.24
Tasks: 174 total,   1 running, 173 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.3 us,  4.8 sy,  0.0 ni, 90.1 id,  0.0 wa,  0.9 hi,  2.0 si,  0.0 st
MiB Mem :   3780.5 total,   1919.4 free,   1083.9 used,    777.2 buff/cache
MiB Swap:   4096.0 total,   3997.7 free,     98.2 used.   2446.1 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                                
 4308 root      20   0  714216  16792   7096 S  43.0   0.4   4952:15 imsocket                                                                                               
31162 root      10 -10  178092  27356  11056 S   0.7   0.7 288:37.93 AliYunDun                                                                                              
16435 root      20   0   64096   4448   3800 R   0.3   0.1   0:00.30 top                                                                                                    
    1 root      20   0  242352   7524   5332 S   0.0   0.2   3:22.53 systemd                                                                                                
    2 root      20   0       0      0      0 S   0.0   0.0   0:02.80 kthreadd                                                                                               
    3 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_gp          

空白行之后是进程的实时信息，每个进程都有一个 %CPU 列，表示进程的 CPU 使用率。它是用户态和内核态 CPU 使用率的总和，包括进程用户空间使用的 CPU、 通过系统调用执行的内核空间 CPU 、以及在就绪队列等待运行的 CPU。在虚拟化环境 中，它还包括了运行虚拟机占用的 CPU。

top 并没有细分进程的用户态 CPU 和内核态 CPU。那要怎 么查看每个进程的详细情况呢?你应该还记得上一节用到的 pidstat 吧，它正是一个专门分析每个进程 CPU 使用情况的工具。
比如， pidstat 命令，就间隔 1 秒展示了进程的 5 组 CPU 使用率，包括:

pidstat -u 1
11时20分16秒   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
11时20分17秒     0      4308    0.00   42.57    0.00    0.00   42.57     3  imsocket
11时20分17秒     0     16483    0.00    0.99    0.00    0.00    0.99     1  pidstat
11时20分17秒     0     31162    0.00    0.99    0.00    0.00    0.99     0  AliYunDun
....
平均时间:   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
平均时间:     0       860    0.00    0.20    0.00    0.00    0.20     -  rngd
平均时间:     0      4308    0.00   42.80    0.00    0.00   42.80     -  imsocket
平均时间:     0     16534    0.20    0.60    0.00    0.00    0.80     -  pidstat

1. 用户态 CPU 使用率 (%usr)
2. 内核态 CPU 使用率(%system)
3. 运行虚拟机 CPU 使用率(%guest)
4. 等待 CPU 使用率(%wait)
5. 以及总的 CPU 使用率(%CPU)

最后的 “平均时间” 部分，还计算了 5 组数据的平均值。

CPU 使用率过高怎么办?

通过 top、ps、pidstat 等工具，能够轻松找到 CPU 使用率较高(比如 100% )的进 程。那么，占用 CPU 的到底是代码里的哪个函数呢？找到它，你才能更高效、更针对性地进行优化。

普通用的都是是 GDB(The GNU Project Debugger)， 这个功能强大的程序调试利器。的确，GDB 在调试程序错误方面很强大。但是GDB 并不适合在性能分析的早期应用。因为 GDB 调试程序的过程会中断程序运行，这在线上环境往往是不允许的。 所以，GDB 只适合用在性能分析的后期，当我们找到了出问题的大致函数后，线下再借助它来进一步调试函数内部的问题。

推荐使用perf。perf 是 Linux 2.6.31 以后内置的性能分析工具。它以性能事件采样为基础，不仅可以分析系统的各种事件和内核性能，还可以用来分析指定应用程序的性能问题。

使用 perf 分析 CPU 性能问题，有两种最常见、也是我最喜欢的用法。
第一种常见用法是 perf top，类似于 top，它能够实时显示占用 CPU 时钟最多的函数或 者指令，因此可以用来查找热点函数，使用界面如下所示:

perf top -g
Samples: 785K of event 'cpu-clock:pppH', 4000 Hz, Event count (approx.): 8358801205 lost: 0/0 drop: 0/0
 Overhead     Shared Object                                           Symbol
32.52%         0.04%  imsocket                                [.] imsocketio/events.ListeningClose
22.03%         2.86%  [kernel]                              [k] __softirqentry_text_start


....
   

输出结果中，第一行包含三个数据，分别是采样数(Samples)、事件类型(event)和 事件总数量(Event count)。比如这个例子中，perf 总共采集了 785K CPU 时钟事件，而总事件数则为 8358801205。

另外，采样数需要我们特别注意。如果采样数过少(比如只有十几个)，那下面的排序和 百分比就没什么实际参考价值了。
再往下看是一个表格式样的数据，每一行包含四列，分别是:

1. 第一列 Overhead ，是该符号的性能事件在所有采样中的比例，用百分比来表示
2. 第二列 Shared ，是该函数或指令所在的动态共享对象(Dynamic Shared Object)， 如内核、进程名、动态链接库名、内核模块名等。
3. 第三列 Object ，是动态共享对象的类型。比如 [.] 表示用户空间的可执行程序、或者动态链接库，而 [k] 则表示内核空间。
4. 最后一列 Symbol 是符号名，也就是函数名。当函数名未知时，用十六进制的地址来表示。
   以上面的输出为例，我们可以看到，占用 CPU 时钟最多的是 imsocket不过它 的比例有 32.52%，说明系统 CPU 性能问题并不大，但是这个可以进行优化。 perf top 的使用应该很清楚了吧。

接着再来看第二种常见用法，也就是 perf record 和 perf report。 perf top 虽然实时展 示了系统的性能信息，但它的缺点是并不保存数据，也就无法用于离线或者后续的分析。 而 perf record 则提供了保存数据的功能，保存后的数据，需要你用 perf report 解析展示。

perf record -g

案例

下面我们就以 Nginx + PHP 的 Web 服务为例，来看看当你发现 CPU 使用率过高的问题后，要怎么使用 top 等工具找出异常的进程，又要怎么利用 perf 找出引发性能问题的函数。

这次新使用的工具 ab。ab(apache bench)是一个常用的 HTTP 服务 性能测试工具，这里用来模拟 Ngnix 的客户端。

我们来测试一下这个 Nginx 服务的性能。在终端运行下面的 ab 命令:

# 并发 10 个请求测试 Nginx 性能，总共测试 100 个请求
ab -c 10 -n 100 http://api.tickeup.com:80/
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
....
Requests per second:    38.73 [#/sec] (mean)
Time per request:       258.206 [ms] (mean)
....

从 ab 的输出结果我们可以看到，Nginx 能承受的每秒平均请求数只有 38.73。这和很人想吐槽，这也太差了吧。那到底是哪里出了问题呢?我们用 top 和 pidstat 再来观察下。

这次，我们将测试的请求总数增加到 10000。然后打开一个新的终端使用性能分析工具时， Nginx 的压力还是继续。

ab -c 10 -n 10000 http://api.tickeup.com:80/
top
Tasks: 143 total,  15 running, 128 sleeping,   0 stopped,   0 zombie
%Cpu0  : 92.6 us,  7.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  0.0 si,  0.0 st
%Cpu1  : 93.0 us,  6.3 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  0.3 si,  0.0 st
MiB Mem :   3637.6 total,    277.4 free,    753.9 used,   2606.4 buff/cache
MiB Swap:   4096.0 total,   4092.5 free,      3.5 used.   2612.8 avail Mem 

PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                                
24043 www       20   0  220252  23812  11468 S  11.3   0.6   0:03.85 php-fpm                                                                                                
16757 www       20   0  294252  25808  13108 S   8.6   0.7   0:12.59 php-fpm                                                                                                
21070 www       20   0  293984  25612  13108 R   7.3   0.7   0:11.42 php-fpm                                                                                                
 9343 www       20   0  302804  29544  15696 R   7.0   0.8   0:30.20 php-fpm                                                                                                
 9350 www       20   0  299812  26304  13400 S   7.0   0.7   0:29.82 php-fpm                                                                                                
14322 www       20   0  293984  25636  13108 R   6.6   0.7   0:11.82 php-fpm                                                                                                
18396 www       20   0  294116  25432  12916 S   6.6   0.7   0:11.76 php-fpm                                                                                                
20186 www       20   0  294020  25424  12916 R   6.6   0.7   0:12.22 php-fpm                                                                                                
....    

可以看到，系统中有几个 php-fpm 进程的 CPU 使用率加起来接近 200%;而每个 CPU 的用户使用率(us)也已经超过了 98%，接近饱和。这样，我们就可以确认，正是 用户空间的 php-fpm 进程，导致 CPU 使用率骤升。

那再往下走，怎么知道是 php-fpm 的哪个函数导致了 CPU 使用率升高呢?我们来用 perf 分析一下。在第二终端运行下面的 perf 命令:

# -g 开启调用关系分析，-p 指定 php-fpm 的进程号 21515
perf top -g -p 21515

总结

CPU 使用率是最直观和最常用的系统性能指标，更是我们在排查性能问题时，通常会关注的第一个指标。所以我们更要熟悉它的含义，尤其要弄清楚用户(%user)、 Nice(%nice)、系统(%system) 、等待 I/O(%iowait) 、中断(%irq)以及软中 断(%softirq)这几种不同 CPU 的使用率。比如说:

1. 用户 CPU 和 Nice CPU 高，说明用户态进程占用了较多的 CPU，所以应该着重排查进程的性能问题。
2. 系统 CPU 高，说明内核态占用了较多的 CPU，所以应该着重排查内核线程或者系统调 用的性能问题。
3. I/O 等待 CPU 高，说明等待 I/O 的时间比较长，所以应该着重排查系统存储是不是出现 了 I/O 问题。
4. 软中断和硬中断高，说明软中断或硬中断的处理程序占用了较多的 CPU，所以应该着重 排查内核中的中断服务程序。
   碰到 CPU 使用率升高的问题，你可以借助 top、pidstat 等工具，确认引发 CPU 性能问 题的来源；再使用 perf 等工具，排查出引起性能问题的具体函数。

碰到常规问题无法解释的 CPU 使用率情况时，首先要想到有可能是短时应用导致的问题， 比如有可能是下面这两种情况：

1. 第一，应用里直接调用了其他二进制程序，这些程序通常运行时间比较短，通过 top 等 工具也不容易发现。
2. 第二，应用本身在不停地崩溃重启，而启动过程的资源初始化，很可能会占用相当多的 CPU。