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

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

CPU 使用率是单位时间内 CPU 使用情况的统计，以百分比的方式展示。

问题：CPU 使用率到底是怎么算出来的？再有，诸如 ​​top​​​、​​ps​​​ 之类的性能工具展示的 ​​%user​​​、​​%nice​​​、 ​​%system​​​、​​%iowait​​​ 、​​%steal​​ 等等，它们之间又有什么不同吗？

一、CPU使用率

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

1.1、节拍率

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

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

$ grep 'CONFIG_HZ=' /boot/config-$(uname -r)CONFIG_HZ=250

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

1.2、​​proc​​虚拟文件系统

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

# 只保留各个CPU的数据$ cat /proc/stat | grep ^cpucpu 280580 7407 286084 172900810 83602 0 583 0 0 0cpu0 144745 4181 176701 86423902 52076 0 301 0 0 0cpu1 135834 3226 109383 86476907 31525 0 282 0 0 0

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

说明：这里每一列的顺序并不需要背下来。只要记住，有需要的时候，查询 man proc 就可以。

​​man proc​​ 文档里每一列的涵义，它们都是 CPU 使用率相关的重要指标。

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 使用率，所以要注意间隔时间的设置，特别是用多个工具对比分析时，一定要保证它们用的是相同的间隔时间。

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

二、怎么查看CPU使用率

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

top的输出格式

# 默认每3秒刷新一次$ toptop - 11:58:59 up 9 days, 22:47, 1 user, load average: 0.03, 0.02, 0.00Tasks: 123 total, 1 running, 72 sleeping, 0 stopped, 0 zombie%Cpu(s): 0.3 us, 0.3 sy, 0.0 ni, 99.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 stKiB Mem : 8169348 total, 5606884 free, 334640 used, 2227824 buff/cacheKiB Swap: 0 total, 0 free, 0 used. 7497908 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 20 0 78088 9288 6696 S 0.0 0.1 0:16.83 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.05 kthreadd 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H...

注意：top 默认显示的是所有 CPU 的平均值，按下数字 1 ，就可以切换到每个 CPU 的使用率了。

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

​​top​​ 并没有细分进程的用户态 CPU 和内核态 CPU。要想查看每个进程的详细情况，使用 pidstat ，是专门分析每个进程 CPU 使用情况的工具。

下面 ​​pidstat​​ 命令，间隔 1 秒展示了进程的 5 组 CPU 使用率，包括：

用户态 CPU 使用率(%usr)；内核态 CPU 使用率（%system）；运行虚拟机 CPU 使用率（%guest）；等待 CPU 使用率（%wait）；以及总的 CPU 使用率（%CPU）。

最后的 Average 部分，还计算了 5 组数据的平均值。

# 每隔1秒输出一组数据，共输出5组$ pidstat 1 515:56:02 UID PID %usr %system %guest %wait %CPU CPU Command15:56:03 0 15006 0.00 0.99 0.00 0.00 0.99 1 dockerd...Average: UID PID %usr %system %guest %wait %CPU CPU CommandAverage: 0 15006 0.00 0.99 0.00 0.00 0.99 - dockerd

三、CPU使用率过高怎么办

通过 ​​top、ps、pidstat​​ 等工具，你能够轻松找到 CPU 使用率较高（比如 100% ）的进程。接下来，你可能又想知道，占用 CPU 的到底是代码里的哪个函数呢？找到它，你才能更高效、更针对性地进行优化。

GDB（The GNU Project Debugger）， 这个功能强大的程序调试利器。的确，GDB 在调试程序错误方面很强大。但是并不适合在性能分析的早期应用。

因为 GDB 调试程序的过程会中断程序运行，这在线上环境往往是不允许的。GDB 只适合用在性能分析的后期，当你找到了出问题的大致函数后，线下再借助它来进一步调试函数内部的问题。

3.1、哪种工具适合在第一时间分析进程的CPU问题？

推荐 perf

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

3.2、使用​​perf​​分析CPU性能问题，常见两种用法

3.2.1、第一种：​​perf top​​

类似 top ，它能够实时显示占用 CPU 时钟最多的函数或者指令，因此可以用来查找热点函数。

$ perf topSamples: 833 of event 'cpu-clock', Event count (approx.): 97742399Overhead Shared Object Symbol 7.28% perf [.] 0x00000000001f78a4 4.72% [kernel] [k] vsnprintf 4.32% [kernel] [k] module_get_kallsym 3.65% [kernel] [k] _raw_spin_unlock_irqrestore...

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

采样数需要我们特别注意。如果采样数过少（比如只有十几个），那下面的排序和百分比就没什么实际参考价值了。

再往下看是一个表格式样的数据，每一行包含四列，分别是：

第一列​​Overhead​​ ，是该符号的性能事件在所有采样中的比例，用百分比来表示。第二列​​Shared​​ ，是该函数或指令所在的动态共享对象（Dynamic Shared Object），如内核、进程名、动态链接库名、内核模块名等。第三列​​Object​​ ，是动态共享对象的类型。比如 [.] 表示用户空间的可执行程序、或者动态链接库，而 [k] 则表示内核空间。最后一列​​Symbol​​ 是符号名，也就是函数名。当函数名未知时，用十六进制的地址来表示。

还是以上面的输出为例，我们可以看到，占用 CPU 时钟最多的是 perf 工具自身，不过它的比例也只有 7.28%，说明系统并没有 CPU 性能问题。

3.2.2、第二种：​​perf record​​ 和 ​​perf report​​

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

$ perf record # 按Ctrl+C终止采样[ perf record: Woken up 1 times to write data ][ perf record: Captured and wrote 0.452 MB perf.data (6093 samples) ]$ perf report # 展示类似于perf top的报告

在实际使用中，我们还经常为 perf top 和 perf record 加上 -g 参数，开启调用关系的采样，方便我们根据调用链来分析性能问题。

四、案例

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

4.1、环境准备

基于Ubuntu 18.04，或其他Linux系统机器配置：2 CPU、8GB 内存预先安装​​docker、sysstat、perf、ab​​​等工具，如​​apt install docker.io sysstat linux-tools-common apache2-utils​​

4.2、ab工具

ab（apache bench）是一个常用的 HTTP 服务性能测试工具，这里用来模拟 Ngnix 的客户端。由于 Nginx 和 PHP 的配置比较麻烦，将它们打包成了两个 ​​Docker​​ 镜像，这样只需要运行两个容器，就可以得到模拟环境。

注意：案例需要用到两台虚拟机

(1) 一台用作 Web 服务器，来模拟性能问题；(2) 另一台用作 Web 服务器的客户端，来给 Web 服务增加压力请求。

4.3、操作和分析

4.3.1、终端一：执行下面的命令来运行 Nginx 和 PHP 应用

$ git clone git@gitee.com:liushiju/linux_performance_examples.git$ cd linux_performance_examples/nginx-high-cpu$ make build$ docker run --name nginx -p 10000:80 -itd liushiju/nginx:cpu$ docker run --name phpfpm -itd --network container:nginx liushiju/php-fpm:cpu

4.3.2、终端二：使用 curl 访问 ​​的 IP]:10000​​，确认 Nginx 已正常启动。

# 192.168.0.10是第一台虚拟机的IP地址$ curl works!

4.3.3、终端二：测试 Nginx 服务的性能，运行下面的 ​​ab​​ 命令

# 并发10个请求测试Nginx性能，总共测试100个请求$ ab -c 10 -n 100 is ApacheBench, Version 2.3 <$Revision: 1706008 $>Copyright 1996 Adam Twiss, Zeus Technology Ltd, ...Requests per second: 11.63 [#/sec] (mean)Time per request: 859.942 [ms] (mean)...

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

4.3.4、终端二：将测试的请求总数增加到 10000。这样当你在第一个终端使用性能分析工具时， Nginx 的压力还是继续。

$ ab -c 10 -n 10000 top 命令，并按下数字 1 ，切换到每个 CPU 的使用率

$ top...%Cpu0 : 98.7 us, 1.3 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st%Cpu1 : 99.3 us, 0.7 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st... PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND21514 daemon 20 0 336696 16384 8712 R 41.9 0.2 0:06.00 php-fpm21513 daemon 20 0 336696 13244 5572 R 40.2 0.2 0:06.08 php-fpm21515 daemon 20 0 336696 16384 8712 R 40.2 0.2 0:05.67 php-fpm21512 daemon 20 0 336696 13244 5572 R 39.9 0.2 0:05.87 php-fpm21516 daemon 20 0 336696 16384 8712 R 35.9 0.2 0:05.61 php-fpm

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

4.3.6、怎么知道是 php-fpm 的哪个函数导致了 CPU 使用率升高呢？

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

按方向键切换到 php-fpm，再按下回车键展开 php-fpm 的调用关系，你会发现，调用关系最终到了 sqrt 和 add_function。看来，我们需要从这两个函数入手了。

4.3.7、拷出 ​​Nginx 应用的源码​​，看看是不是调用了这两个函数

# 从容器phpfpm中将PHP源码拷贝出来$ docker cp phpfpm:/app .# 使用grep查找函数调用$ grep sqrt -r app/ #找到了sqrt调用app/index.php: $x += sqrt($x);$ grep add_function -r app/ #没找到add_function调用，这其实是PHP内置函数

原来只有 sqrt 函数在 app/index.php 文件中调用了。那最后一步，我们就该看看这个文件的源码了

$ cat app/index.php

原因：测试代码没删就直接发布应用了。

4.3.8、修复问题

为了方便验证优化后的效果，把修复后的应用也打包成了一个 Docker 镜像，可以在第一个终端中执行下面的命令来运行它

# 停止原来的应用$ docker rm -f nginx phpfpm# 运行优化后的应用$ git clone git@gitee.com:liushiju/linux_performance_examples.git$ cd linux_performance_examples/nginx-high-cpu-fix$ make build$ docker run --name nginx -p 10000:80 -itd liushiju/nginx:cpu-fix$ docker run --name phpfpm -itd --network container:nginx liushiju/php-fpm:cpu-fix

4.3.9、修复后验证

到第二个终端来验证一下修复后的效果。首先 Ctrl+C 停止之前的 ab 命令后，再运行下面的命令

$ ab -c 10 -n 10000 requests: 10000Failed requests: 0Total transferred: 1720000 bytesHTML transferred: 90000 bytesRequests per second: 2237.04 [#/sec] (mean)Time per request: 4.470 [ms] (mean)Time per request: 0.447 [ms] (mean, across all concurrent requests)Transfer rate: 375.75 [Kbytes/sec] received...

从这里可以发现，现在每秒的平均请求数，已经从原来的 11 变成了 2237。

五、小结

CPU 使用率是最直观和最常用的系统性能指标，更是我们在排查性能问题时，通常会关注的第一个指标。

熟悉含义： 用户（%user）、Nice（%nice）、系统（%system） 、等待 I/O（%iowait） 、中断（%irq）以及软中断（%softirq）这几种不同 CPU 的使用率。

比如：

用户 CPU 和 Nice CPU 高，说明用户态进程占用了较多的 CPU，所以应该着重排查进程的性能问题。系统 CPU 高，说明内核态占用了较多的 CPU，所以应该着重排查内核线程或者系统调用的性能问题。I/O 等待 CPU 高，说明等待 I/O 的时间比较长，所以应该着重排查系统存储是不是出现了 I/O 问题。软中断和硬中断高，说明软中断或硬中断的处理程序占用了较多的 CPU，所以应该着重排查内核中的中断服务程序。

碰到 CPU 使用率升高的问题，可以借助 ​​top​​​、​​pidstat​​​ 等工具，确认引发 CPU 性能问题的来源；再使用 ​​perf​​ 等工具，排查出引起性能问题的具体函数。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。