cpu使用率

最新推荐文章于 2024-08-24 15:46:50 发布

菠萝炒饭pineapple-boss

最新推荐文章于 2024-08-24 15:46:50 发布

阅读量186

点赞数

文章标签： linux 运维服务器

本文链接：https://blog.csdn.net/weixin_44923842/article/details/132803306

版权

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

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

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

250，也就是每秒钟触发 250 次时间中断。

root@debian:~# grep 'CONFIG_HZ=' /boot/config-$(uname -r)
CONFIG_HZ=250

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

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

root@debian:~# cat /proc/stat
cpu  243897 2504 138383 140186999 50356 0 4306 339302 0 0
cpu0 55727 499 34783 35068074 13472 0 2210 78262 0 0
cpu1 51577 204 35768 35037050 25370 0 755 74641 0 0
cpu2 55232 574 34049 35069627 3392 0 1181 77154 0 0
cpu3 81359 1225 33780 35012247 8121 0 159 109243 0 0
intr 48564566 44 1489 0 0 0 0 3 0 1 0 0 176204 2665 0 699731 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1212492 0 2233675 86994 0 27 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ctxt 414768855
btime 1694050393
processes 146264
procs_running 1
procs_blocked 0
softirq 24317603 2 6185823 2 2320330 1562665 0 1987 9367903 0 4878891
cat: cpu: No such file or directory

这里的输出结果是一个表格。其中，第一列表示的是 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 使用率。

这是开机以来的节拍数累加值，所以直接算出来的，是开机以来的平均 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 的输出格式为：

 # 默认每 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

这个输出结果中，第三行 %Cpu 就是系统的 CPU 使用率，具体每一列的含义上一节都讲过，只是把 CPU 时间变换成了 CPU 使用率。

不过需要注意，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 组数据的平均值。

root@debian:~# pidstat 1 5
Linux 5.10.0-23-amd64 (debian) 	09/22/23 	_x86_64_	(4 CPU)

02:36:37      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
02:36:38        0    152568    0.00    0.99    0.00    0.00    0.99     3  top

02:36:38      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
02:36:39        0    162930    1.00    1.00    0.00    0.00    2.00     2  pidstat

02:36:39      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
02:36:40        0    162930    1.00    0.00    0.00    0.00    1.00     2  pidstat

02:36:40      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
02:36:41        0    162930    0.00    1.00    0.00    0.00    1.00     2  pidstat

02:36:41      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
02:36:42        0    162930    0.00    1.00    0.00    0.00    1.00     2  pidstat

Average:      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
Average:        0    152568    0.00    0.20    0.00    0.00    0.20     -  top
Average:        0    162930    0.40    0.60    0.00    0.00    1.00     -  pidstat

CPU 使用率过高怎么办？

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

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

使用 perf 分析 CPU 性能问题，我来说两种最常见、也是我最喜欢的用法。

第一种常见用法是 perf top，类似于 top，它能够实时显示占用 CPU 时钟最多的函数或者指令，因此可以用来查找热点函数，使用界面如下所示：

输出结果中，第一行包含三个数据，分别是采样数（Samples）、事件类型（event）和事件总数量（Event count）。

比如这个例子中，perf 总共采集了 1k 个 CPU 时钟事件，而总事件数则为236031250。

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

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

还是以上面的输出为例，可以看到，占用 CPU 时钟最多的是 perf 工具自身，不过它的比例也只有 7.28%，说明系统并没有 CPU 性能问题。 perf top 的使用你应该很清楚了吧。

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

perf record # 按 Ctrl+C 终止采样 perf report # 展示类似于 perf top 的报告

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

案例

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

预先安装 docker、sysstat、perf、ab 等工具，如

yum install docker-ce sysstat linux- tools-common apache2-utils

我先简单介绍一下这次新使用的工具 ab。ab（apache bench）是一个常用的 HTTP 服务性能测试工具，这里用来模拟 Ngnix 的客户端。由于 Nginx 和 PHP 的配置比较麻烦，我

把它们打包成了两个 Docker 镜像，这样只需要运行两个容器，就可以得到模拟环境。注意，这个案例要用到两台虚拟机，如下图所示：

你可以看到，其中一台用作 Web 服务器，来模拟性能问题；另一台用作 Web 服务器的客户端，来给 Web 服务增加压力请求。使用两台虚拟机是为了相互隔离，避免“交叉感染”。

操作和分析

首先，在第一个终端执行下面的命令来运行 Nginx 和 PHP 应用：

docker run --name nginx -p 10000:80 -itd feisky/nginx 
docker run --name phpfpm -itd --network container:nginx feisky/php-fpm

然后，在第二个终端使用 curl 访问 http://[VM1 的 IP]:10000，确认 Nginx 已正常启动。你应该可以看到 It works! 的响应。

 # 192.168.113.220 是第一台虚拟机的 IP 地址
$ curl http://127.0.0.1:10000
 It works!

接着，我们来测试一下这个 Nginx 服务的性能。在第二个终端运行下面的 ab 命令：

# 并发 10 个请求测试 Nginx 性能，总共测试 100 个请求

# 并发 10 个请求测试 Nginx 性能，总共测试 100 个请求
$ ab -c 10 -n 100 http://127.0.0.1:10000/
Server Software:        nginx/1.15.4
Server Hostname:        192.168.113.220
Server Port:            10000

Document Path:          /
Document Length:        9 bytes

Concurrency Level:      10
Time taken for tests:   3.540 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      17200 bytes
HTML transferred:       900 bytes
Requests per second:    28.25 [#/sec] (mean) #每秒请求
Time per request:       354.023 [ms] (mean)
Time per request:       35.402 [ms] (mean, across all concurrent requests)
Transfer rate:          4.74 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       1
Processing:   130  334 179.3    248     747
Waiting:      129  334 179.2    248     746
Total:        131  334 179.2    248     747

Percentage of the requests served within a certain time (ms)
  50%    248
  66%    358
  75%    432
  80%    511
  90%    682
  95%    722
  98%    742
  99%    747
 100%    747 (longest request)

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

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

继续在第二个终端，运行 ab 命令：

ab -c 10 -n 10000 http://127.0.0.1:10000/

接着，回到第一个终端运行 top 命令，并按下数字 1 ，切换到每个 CPU 的使用率：

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

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

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

$ perf top -g -p 4190

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

我们拷贝出 Nginx 应用的源码，看看是不是调用了这两个函数：

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

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

[root@xm-test-cbs-113-220 app]# cat index.php 
<?php
// test only.
$x = 0.0001;
for ($i = 0; $i <= 1000000; $i++) {
  $x += sqrt($x);
}

echo "It works!"

呀，有没有发现问题在哪里呢？我想你要笑话我了，居然犯了一个这么傻的错误，测试代码没删就直接发布应用了。为了方便你验证优化后的效果，我把修复后的应用也打包成了一个 Docker 镜像，你可以在第一个终端中执行下面的命令来运行它：

# 停止原来的应用
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

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

[root@xm-test-cbs-113-220 app]#  ab -c 10 -n 10000 http://127.0.0.1:10000/
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        nginx/1.15.6
Server Hostname:        127.0.0.1
Server Port:            10000

Document Path:          /
Document Length:        9 bytes

Concurrency Level:      10
Time taken for tests:   3.345 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      1720000 bytes
HTML transferred:       90000 bytes
Requests per second:    2989.83 [#/sec] (mean) #####
Time per request:       3.345 [ms] (mean)
Time per request:       0.334 [ms] (mean, across all concurrent requests)
Transfer rate:          502.20 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       2
Processing:     1    3  23.4      2     456
Waiting:        0    3  23.0      2     456
Total:          1    3  23.4      2     456

Percentage of the requests served within a certain time (ms)
  50%      2
  66%      2
  75%      2
  80%      3
  90%      3
  95%      3
  98%      4
  99%      5
 100%    456 (longest request)

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

就是这么很傻的一个小问题，却会极大的影响性能，并且查找起来也并不容易吧。当然，找到问题后，解决方法就简单多了，删除测试代码就可以了。

小结

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 等工具，排查出引起性能问题的具体函数。

菠萝炒饭pineapple-boss

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
cpu使用率

Linux 作为一个多任务操作系统，将每个CPU的时间划分为很短的时间片，再通过调度器轮流分配给各个任务使用，因此造成多任务同时运行的错觉。为了维护CPU时间，Linux通过事先定义的节拍率（内核中表示为 HZ），触发时间中断，并使用全局变量 Jiffies 记录了开机以来的节拍数。每发生一次时间中断，Jiffies 的值就加 1。节拍率 HZ 是内核的可配选项，可以设置为 100、250、1000 等。不同的系统可能设置不同数值，可以通过查询 /boot/config 内核选项来查看它的配置值。
复制链接

扫一扫