CPU使用率概念
Linux作为一个多任务操作系统，将每个CPU的时间划分为很短的时间片，再通过调度器轮流分配给各个任务使用，因此造成多任务同时运行的错觉
为了维护CPU时间，Linux通过事先定义的节拍率（内核中表示为HZ），触发时间中断
并使用全局变量Jiffies记录了开机以来的节拍数。每发生一次时间中断，Jiffies的值就加1
节拍率HZ是内核的可配选项，可以设置为100、250、1000等
不同的系统可能设置不同数值，可以通过查询/boot/config内核选项来查看它的配置值
比如在我的系统中，节拍率设置成了1000，也就是每秒钟触发1000次时间中断
[root@local_sa_192-168-1-6 ~]# grep "CONFIG_HZ=" /boot/config-`uname -r`
CONFIG_HZ=1000
同时，正因为节拍率HZ是内核选项，所以用户空间程序并不能直接访问
为了方便用户空间程序，内核还提供了一个用户空间节拍率USER_HZ
它总是固定为100，也就是1/100秒
这样，用户空间程序并不需要关心内核中HZ被设置成了多少，因为它看到的总是固定值USER_HZ
Linux通过/proc虚拟文件系统，向用户空间提供了系统内部状态的信息
而/proc/stat提供的就是系统的CPU和任务统计信息
比方说，如果只关注CPU的话，可以执行下面的命令
[root@local_sa_192-168-1-6 ~]# cat /proc/stat |grep ^cpu
cpu 253484 65 138912 33981119 60959 0 187 1363 0 0
cpu0 145515 28 70112 16971015 28062 0 106 619 0 0
cpu1 107969 37 68799 17010103 32897 0 81 744 0 0
第一列表示的是CPU编号，如cpu0、cpu1
第一行没有编号的cpu，表示的是所有CPU的累加
其他列则表示不同场景下CPU的累加节拍数，它的单位是USER_HZ，也就是10 ms（1/100秒）
所以这其实就是不同场景下的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使用率，性能工具一般都会取间隔一段时间（比如3秒）的两次值，作差后，再计算出这段时间内的平均CPU使用率
这个公式，就是我们用各种性能工具所看到的CPU使用率的实际计算方法
现在，我们知道了系统CPU使用率的计算方法，那进程的呢？
跟系统的指标类似，Linux也给每个进程提供了运行情况的统计信息
也就是/proc/[pid]/stat
不过，这个文件包含的数据就比较丰富了，总共有52列的数据
那么查看CPU使用率，就必须先读取/proc/stat和/proc/[pid]/stat这两个文件，然后再按照上面的公式计算出来呢？
当然不是，各种各样的性能分析工具已经帮我们计算好了
不过要注意的是，性能分析工具给出的都是间隔一段时间的平均CPU使用率
所以要注意间隔时间的设置，特别是用多个工具对比分析时，一定要保证它们用的是相同的间隔时间
比如，对比一下top和ps这两个工具报告的CPU使用率，默认的结果很可能不一样
因为top默认使用3秒时间间隔，而ps使用的却是进程的整个生命周期
[root@local_sa_192-168-1-6 ~]# ps -l
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
......
0 R 0 15751 12605 0 80 0 - 38311 - pts/0 00:00:00 ps
# C CPU 使用的资源百分比
怎么查看CPU使用率
查看CPU使用率常用工具
【top】显示了系统总体的CPU和内存使用情况，以及各个进程的资源使用情况
【ps】则只显示了每个进程的资源使用情况
[root@local_sa_192-168-1-6 ~]# top
top - 15:57:52 up 2 days, 3 min, 1 user, load average: 0.00, 0.01, 0.05
Tasks: 177 total, 1 running, 176 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.2 us, 0.0 sy, 0.0 ni, 99.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
......
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14687 root 20 0 164104 2324 1568 R 0.3 0.1 0:00.01 top
......
第三行%Cpu就是系统的CPU使用率
top默认显示的是所有CPU的平均值，这个时候你只需要按下数字1，就可以切换到每个CPU的使用率了
空白行之后是进程的实时信息，每个进程都有一个%CPU列，表示进程的CPU使用率
它是用户态和内核态CPU使用率的总和，包括进程用户空间使用的CPU、通过系统调用执行的内核空间CPU 、
以及在就绪队列等待运行的CPU，在虚拟化环境中，它还包括了运行虚拟机占用的CPU
到这里我们可以发现，top并没有细分进程的用户态CPU和内核态CPU。那要怎么查看每个进程的详细情况呢？
【pidstat】正是一个专门分析每个进程CPU使用情况的工具
# 每隔1秒输出一组数据，共输出5组
[root@local_sa_192-168-1-6 ~]# pidstat 1 5
Linux 3.10.0-1160.31.1.el7.x86_64 (local_sa_192-168-1-6) 2021年11月10日 _x86_64_ (2 CPU)
16时01分01秒 UID PID %usr %system %guest %wait %CPU CPU Command
16时01分02秒 0 14851 0.00 0.99 0.00 0.00 0.99 1 pidstat
# 输出结果分析
# 用户态CPU使用率 （%usr）
# 内核态CPU使用率（%system）
# 运行虚拟机CPU使用率（%guest）
# 等待CPU使用率（%wait）
# 以及总的 CPU 使用率（%CPU）
CPU使用率过高怎么办?
通过top、ps、pidstat等工具，能够轻松找到CPU使用率较高（比如100%）的进程
那么占用CPU的到底是代码里的哪个函数呢？
只有找到它，才能更高效、更针对性地进行优化
GDB（The GNU Project Debugger），这个功能强大的程序调试利器
的确，GDB在调试程序错误方面很强大
但是，GDB并不适合在性能分析的早期应用
因为GDB调试程序的过程会中断程序运行，这在线上环境往往是不允许的
所以，GDB只适合用在性能分析的后期，当找到了出问题的大致函数后，线下再借助它来进一步调试函数内部的问题
【perf】是Linux 2.6.31以后内置的性能分析工具
它以性能事件采样为基础，不仅可以分析系统的各种事件和内核性能，还可以用来分析指定应用程序的性能问题
【perf】分析CPU性能问题，两种最常见的用法
# 第一种方法
perf top，类似于top，它能够实时显示占用CPU时钟最多的函数或者指令，因此可以用来查找热点函数
[root@local_sa_192-168-1-6 ~]# perf top
Samples: 1K of event 'cpu-clock', 4000 Hz, Event count (approx.): 251812500 lost: 0/0 drop: 0/0
Overhead Shared Object Symbol
12.68% [kernel] [k] module_get_kallsym
10.34% [kernel] [k] vsnprintf
7.91% [kernel] [k] format_decode
6.08% [kernel] [k] kallsyms_expand_symbol.constprop.1
4.86% [kernel] [k] number.isra.2
3.47% perf [.] rb_next
# 输出结果
# 第一行包含三个数据，分别是采样数（Samples）、事件类型（event）和事件总数量（Event count）
# 比如这个例子中，perf总共采集了1000个CPU时钟事件，而总事件数则为251812500
# 另外，采样数需要我们特别注意。如果采样数过少（比如只有十几个），那下面的排序和百分比就没什么实际参考价值了
# 再往下看是一个表格式样的数据，每一行包含四列，分别是
# 第一列Overhead ，是该符号的性能事件在所有采样中的比例，用百分比来表示
# 第二列Shared ，是该函数或指令所在的动态共享对象（Dynamic Shared Object），如内核、进程名、动态链接库名、内核模块名等
# 第三列Object ，是动态共享对象的类型。比如[.]表示用户空间的可执行程序、或者动态链接库，而[k]则表示内核空间
# 最后一列Symbol是符号名，也就是函数名。当函数名未知时，用十六进制的地址来表示
# 第二种方法
perf record和perf report
perf top虽然实时展示了系统的性能信息，但它的缺点是并不保存数据，也就无法用于离线或者后续的分析
perf record则提供了保存数据的功能，保存后的数据，用perf report解析展示
# 按Ctrl+C终止采样(会在运行该命令的目录下生成perf.data)
[root@local_sa_192-168-1-6 ~]# perf record
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.452 MB perf.data (6093 samples) ]
[root@local_sa_192-168-1-6 ~]# ls -l
-rw------- 1 root root 5493628 11月 10 15:04 perf.data
[root@local_sa_192-168-1-6 ~]# perf report # 展示类似于perf top的报告
在实际使用中，我们还经常为perf top和perf record加上-g参数，
开启调用关系的采样，方便我们根据调用链来分析性能问题
案例
以Nginx+PHP的Web服务为例，当发现CPU使用率过高的问题后，要怎么使用top等工具找出异常的进程
又要怎么利用perf找出引发性能问题的函数
实验环境
# 服务端（192.168.1.6）
配置：2CPU，4G内存，centos7.6_64
预先安装docker、sysstat、perf、ab 等工具（yum install perf httpd-tools sysstat -y）
# 客户端（192.168.1.5）
配置：1CPU，2G内存，centos7.6_64
预先安装ab工具（yum install httpd-tools -y）
ab（apache bench）是一个常用的HTTP服务性能测试工具，这里用来模拟Ngnix的客户端
由于Nginx和PHP的配置比较麻烦，我把它们打包成了两个Docker镜像，这样只需要运行两个容器，就可以得到模拟环境
例要用到两台虚拟机，如下图所示
一台用作Web服务器，来模拟性能问题
另一台用作Web服务器的客户端，来给Web服务增加压力请求
1.在服务端，打开第一个终端执行下面的命令来运行 Nginx 和 PHP 应用
[root@local_sa_192-168-1-6 ~]# docker run --name nginx -p 10000:80 -itd feisky/nginx
[root@local_sa_192-168-1-6 ~]# docker run --name phpfpm -itd --network container:nginx feisky/php-fpm
[root@local_sa_192-168-1-6 ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1fbc1bb55c00 feisky/php-fpm "php-fpm -F --pid /o…" 2 hours ago Up 2 hours phpfpm
558cc67e5df8 feisky/nginx "nginx -g 'daemon of…" 2 hours ago Up 2 hours 0.0.0.0:10000->80/tcp, :::10000->80/tcp nginx
2.在服务端，第二个终端使用curl访问http://[VM1 的 IP]:10000，确认 Nginx 已正常启动
[root@local_sa_192-168-1-6 ~]# curl http://192.168.1.6:10000/
It works!
3.在客户端，测试一下这个Nginx服务的性能，在第二个终端运行下面的ab命令
# 并发10个请求测试Nginx性能，总共测试100个请求
[root@local_deploy_192-168-1-5 ~]# ab -c 10 -n 100 http://192.168.1.6:10000/
......
Requests per second: 24.05 [#/sec] (mean)
Time per request: 415.757 [ms] (mean)
......
从ab的输出结果我们可以看到，
Nginx能承受的每秒平均请求数只有24.05
这也太差了吧。那到底是哪里出了问题呢
我们用top和 pidstat 再来观察下
4.在客户端，将测试的请求总数增加到 10000
[root@local_deploy_192-168-1-5 ~]# ab -c 10 -n 10000 http://192.168.1.6:10000/
5.在服务端，运行top命令，并按下数字1 ，切换到每个CPU的使用率
[root@local_sa_192-168-1-6 ~]# 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+ COMMAND
21514 daemon 20 0 336696 16384 8712 R 41.9 0.2 0:06.00 php-fpm
21513 daemon 20 0 336696 13244 5572 R 40.2 0.2 0:06.08 php-fpm
21515 daemon 20 0 336696 16384 8712 R 40.2 0.2 0:05.67 php-fpm
21512 daemon 20 0 336696 13244 5572 R 39.9 0.2 0:05.87 php-fpm
21516 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使用率骤升
6.在服务端，运行 perf命令（这里选择第二种方法，因为第一种方法在centos上有问题）
6.1第一种方法
[root@local_sa_192-168-1-6 tmp]# perf top -g -p 21514
# 从下图可以看到，函数名称显示为十六进制了，不可读。这个是在centos上才有的问题，Ubuntu上没有该问题
# 所以选择第二种方法
6.1第二种方法
#先运行命令，然后等待15s终止该命令
[root@local_sa_192-168-1-6 ~]# perf record -g -p 21514
[root@local_sa_192-168-1-6 ~]# ls -l
-rw------- 1 root root 5493628 11月 10 15:04 perf.data
# 因为实验环境是容器环境，所以要把perf.data拷贝到容器中去解析
[root@local_sa_192-168-1-6 ~]# docker cp perf.data phpfpm:/tmp
[root@local_sa_192-168-1-6 ~]# docker exec -i -t phpfpm bash
root@2e2f18f5ba75:/app# cd /tmp/
root@2e2f18f5ba75:/tmp# apt-get update && apt-get install -y linux-perf linux-tools procps
root@2e2f18f5ba75:/tmp# chown root.root perf.data
root@2e2f18f5ba75:/tmp# perf_4.9 report
# 注意：最后运行的工具名字是容器内部安装的版本perf_4.9，而不是perf命令
这是因为perf会去跟内核的版本进行匹配
但镜像里面安装的perf版本有可能跟虚拟机的内核版本不一致。
注意：上面的问题只是在centos系统中有问题，ubuntu上没有这个问题
按回车键可以逐层打开
可以发现调用关系最终到了sqrt和add_function
看来，需要从这两个函数入手了
7.在服务端，拷贝出Nginx应用的源码，看看是不是调用了这两个函数
# 从容器phpfpm中将PHP源码拷贝出来
[root@local_sa_192-168-1-6 ~]# docker cp phpfpm:/app .
# 使用grep查找函数调用
[root@local_sa_192-168-1-6 ~]# grep sqrt -r app/ #找到了sqrt调用
app/index.php: $x += sqrt($x);
#没找到add_function调用，这其实是PHP内置函数
[root@local_sa_192-168-1-6 ~]# grep add_function -r app/
# 查看代码，最终定位到有问题的代码函数
[root@local_sa_192-168-1-6 ~]# cat app/index.php
<?php
// test only.
$x = 0.0001;
for ($i = 0; $i <= 1000000; $i++) {
$x += sqrt($x);
}
echo "It works!"
8.在服务端，修复
# 停止原来的应用
[root@local_sa_192-168-1-6 ~]# docker rm -f nginx phpfpm
# 运行优化后的应用
[root@local_sa_192-168-1-6 ~]# docker run --name nginx -p 10000:80 -itd feisky/nginx:cpu-fix
[root@local_sa_192-168-1-6 ~]# docker run --name phpfpm -itd --network container:nginx feisky/php-fpm:cpu-fix
9.在客户端，再次测试
[root@local_deploy_192-168-1-5 ~]# ab -c 10 -n 10000 http://192.168.1.6:10000/
......
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 1720000 bytes
HTML transferred: 90000 bytes
Requests per second: 3718.75 [#/sec] (mean)
Time per request: 2.689 [ms] (mean)
可以发现，现在每秒的平均请求数，变成了3718
小结
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等工具，排查出引起性能问题的具体函数