关于linux系统CPU篇--->CPU使用率升高
1.CPU使用率为单位时间内CPU使用情况的统计，以百分比的方式展示。
LINUX作为一个多任务操作系统，将每个CPU的时间划分为很短的时间片，再通过调度器轮流分配给各个任务使用，因此造成多任务同时运行的错觉
2.如何查看CPU使用率？
TOP和PS是最常用的性能分析工具。TOP显示了系统总体的CPU和内存使用情况，以及各个进程的资源使用情况
PS则只显示了每个进程的资源使用情况
pidstat是专门分析每个进程的CPU使用情况的工具
TOP输出：
# 默认每 3 秒刷新一次
$ top
top - 11:58:59 up 9 days, 22:47, 1 user, load average: 0.03, 0.02, 0.00
Tasks: 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 st
KiB Mem : 8169348 total, 5606884 free, 334640 used, 2227824 buff/cache
KiB 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的使用率了
从top的输出中，可以看到，%CPU列展示的就是CPU使用率：
us:代表用户CPU时间，它不包括nice时间，但是包括guest时间
nice(ni):代表低优先级用户态CPU时间，也就是进程的nice值被调整为1-19之间的CPU时间。这里注意，nice可取值范围是-20到19，数值越大，优先级反而越低。
sy:代表内核态CPU时间
id:代表空闲时间，注意，它不包括等待IO的时间
iowait:通常缩写为wa,代表等待IO的CPU时间
irq:代表处理硬中断的CPU时间
si:代表处理软中断的CPU时间
st:代表系统在运行虚拟机中的时候，被其他虚拟机占用的CPU时间
guest:代表通过虚拟化运行其他操作系统的时间，也就是运行虚拟机的CPU时间
guest_nice(gnice):代表以低优先级运行虚拟机的时间
下面的pidstat命令，就间隔1秒，展示了进程的5组CPU使用率，包括：
%usr用户态CPU使用率
%system 系统CPU使用率
%guest 运行虚拟机CPU使用率
%wait 等待IO CPU使用率
%cpu 总的CPU使用率
最后的average部分，还计算了5组数据的平均值
pidstat输出：
# 每隔 1 秒输出一组数据，共输出 5 组
$ pidstat 1 5
15:56:02 UID PID %usr %system %guest %wait %CPU CPU Command
15: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 Command
Average: 0 15006 0.00 0.99 0.00 0.00 0.99 - dockerd
3.CPU使用率过高怎么办？
使用top,ps,pidstat等工具，能够轻松找到占用CPU使用率较高(100%)的进程,接下来，你可能想知道占用CPU的是哪个函数呢，找到它，才能更有效，更针对性的进行性能优化。
那么那种工具最适合在第一时间分析进程的CPU问题呢，推荐的是perf。perf是linux2.6.31以后内置的性能分析工具，包含了perf top ,perf record,perf report
第一种：perf top，类似于top,它能够实时显示占用CPU时钟最多的函数或者指令，因此可以用来查找热点函数，使用界面如下：
$ perf top
Samples: 833 of event 'cpu-clock', Event count (approx.): 97742399
Overhead 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
...
输出结果中，第一行包含三个数据，分别是采样数，事件类型和事件总数量，输出中可以看到perf采集了833个CPU时钟事件，而总事件数则为97742399
如果输出结果中，采样数(Samples)只有10几个，那下面的排序和百分比就没什么实际参考价值
Overhead:该符号的性能事件，在所有采样中的比例，用百分比来展示
Shared:该函数或指令所在的动态共享对象(Dynamic Shared Object),如内核，进程名，动态连接库名，内核模块名等
Object:动态共享对象的类型。比如[.]表示用户空间的可执行程序，或者动态链接库，而[k]则表示内核空间
Symbol:是符号名，也就是函数名。当函数名未知时，用十六进制地址表示
从上面的输出中可以看到，占用CPU最多的是perf工具自身，不过它的比例也只有7.28%，说明系统并没有CPU性能问题。
第二种常见用法：也就是perf record和perf report
perf record 提供了保存数据的功能，保存后的数据，可以用perf report 解析展示
4.案例分析：
(1).使用两台linux虚拟机，其中一台用作web服务器，模拟性能问题。需要安装docker,nginx,perf,sysstat等工具
另外一台用作客户端，需要安装ab，curl
(2).在第一台虚拟机中执行下面命令运行nginx和php应用：
docker run --name nginx -p 10000:80 -itd feisky/nginx
docker run --name phpfpm -itd --network container:nginx feisky/php-fpm
(3).在第二台虚拟机(客户端)执行curl 命令,确认nginx已经正常启动：
# 192.168.0.10 是第一台虚拟机的 IP 地址
$ curl http://192.168.0.10:10000/
It works!
(4).测试nginx服务的性能：
# 并发 10 个请求测试 Nginx 性能，总共测试 100 个请求
$ ab -c 10 -n 100 http://192.168.0.10:10000/
This 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.性能比较差
(5)继续执行ab，将请求数增加到10000，这样在第一个终端使用性能分析工具时，nginx压力还是继续
ab -c 10 -n 10000 http://192.168.0.10:10000/
(6).回到第一个终端运行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+ 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
发现占用CPU最多的是PHP-fpm进程
(7).怎么知道是php-fpm的那个函数导致了CPU使用率升高呢，我们来用perf分析一下。在第一个终端运行下面的perf命令
# -g 开启调用关系分析，-p 指定 php-fpm 的进程号 21515
$ perf top -g -p 21515
(8).按方向键切换到php-fpm,再按下会车键展开php-fpm的调用关下，发现调用关系最终到了sqrt和add_function
(9).拷贝出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函数在ap/idex.php文件中调用了。看看这个文件的源码：
$ cat app/index.php
<?php
// test only.
$x = 0.0001;
for ($i = 0; $i <= 1000000; $i++) {
$x += sqrt($x);
}
echo "It works!"
发现原来是测试代码没删就直接发布应用了。
(10).优化：
# 停止原来的应用
$ docker rm -f nginx phpfpm
# 运行优化后的应用
$ docker run --name nginx -p 10000:80 -itd feisky/nginx:cpu-fix
$ docker run --name phpfpm -itd --network container:nginx feisky/php-fpm:cpu-fix
(11).重新在第二台虚拟机中测试nginx性能：
$ ab -c 10 -n 10000 http://10.240.0.5:10000/
...
Complete requests: 10000
Failed requests: 0
Total transferred: 1720000 bytes
HTML transferred: 90000 bytes
Requests 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),等待IO(%iowait),中断(%irq),软中断(%softirq)
这几种不同的CPU使用率。
(1).用户和Nice CPU高，说明用户进程占用了较多的CPU,所以应该着重排查进程的性能问题
(2).系统CPU高，说明内核态占用了较多的CPU,所以应该着重排查内核线程或系统调用的性能问题
(3).IO等待CPU高，说明等待IO的时间比较长，应该着重排查系统存储是不是出现了IO问题
(4).软中断和硬中断高，说明软中断或硬中断处理程序占用了较多的CPU,所以应该着重排查内核中的中断服务程序
碰到CPU使用率升高的问题，可以借助TOP,pidstat等工具，确认引发CPU性能问题的来源，再使用perf等工具，排查出引起性能问题的具体函数
