This page looks best with JavaScript enabled

Linux下常见的系统问题分析 cpu使用率过高

 ·  ☕ 7 min read

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 的话,可以执行下面的命令:

1
2
3
4
5
6
$ cat /proc/stat|grep ^cpu
cpu  17631119 11049 10800374 123865682 141642 0 273886 0 0 0
cpu0 4497194 2529 2742844 30789756 32209 0 67782 0 0 0
cpu1 4317177 3569 2657864 31145851 29308 0 68306 0 0 0
cpu2 4497074 2504 2739538 30798541 30448 0 65961 0 0 0
cpu3 4319672 2446 2660126 31131534 49675 0 71836 0 0 0

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

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 使用率,性能工具一般都会取间隔一段时间(比如 3 秒)的两次 值,作差后,再计算出这段时间内的平均 CPU 使用率,即

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

怎么查看cpu使用率

top 和 ps 是最常用的性能分析工 具:

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

  • ps 则只显示了每个进程的资源使用情况。

top

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
# 默认每3秒刷新一次
$ top - 10:00:53 up 4 days, 16:38,  3 users,  load average: 1.42, 1.11, 1.03
Tasks: 379 total,   1 running, 324 sleeping,   0 stopped,   0 zombie
%Cpu0  :  9.2 us, 10.2 sy,  0.0 ni, 80.6 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  : 12.3 us,  7.4 sy,  0.0 ni, 79.9 id,  0.4 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  : 11.9 us,  9.5 sy,  0.0 ni, 78.6 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  : 12.2 us, 10.5 sy,  0.0 ni, 77.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  8071876 total,   194596 free,  2879060 used,  4998220 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  5102912 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 4040 root      20   0 1942132 148460  13756 S  11.3  1.8   1024:33 kubelet
  907 root      20   0   70804   5360   4424 S  10.0  0.1 487:59.20 systemd-logind
   54 root      20   0       0      0      0 S   5.3  0.0  21:43.42 kswapd0
 2425 root      20   0 2542804  92016   6664 S   5.3  1.1 358:58.10 dockerd
  810 message+  20   0   52444   5296   2932 S   5.0  0.1 246:41.94 dbus-daemon
    1 root      20   0  227876  10608   5732 S   4.0  0.1 198:35.18 systemd

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

pidstat

下面的 pidstat 命令,就间隔 1 秒展示了进程的 5 组 CPU 使用率,包括:

  • 用户态 CPU 使用率 (%usr);

  • 内核态 CPU 使用率(%system);

  • 运行虚拟机 CPU 使用率(%guest);

  • 等待 CPU 使用率(%wait);

  • 以及总的 CPU 使用率(%CPU)。

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# 每隔1s输出一组数据,共5组
$ pidstat 1 5
Linux 4.15.0-66-generic (tux-pc) 	11/04/2019 	_x86_64_	(4 CPU)

10:03:38 AM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
10:03:39 AM     0         1    0.98    0.98    0.00    0.00    1.96     0  systemd
10:03:39 AM     0         8    0.00    0.98    0.00    0.98    0.98     2  rcu_sched
10:03:39 AM   103       810    1.96    0.00    0.00    1.96    1.96     0  dbus-daemon
10:03:39 AM     0       907    2.94    2.94    0.00    0.00    5.88     1  systemd-logind
10:03:39 AM     0      2425    3.92    0.98    0.00    0.00    4.90     0  dockerd
10:03:39 AM     0      3522    0.00    1.96    0.00    0.00    1.96     2  kube-controller
10:03:39 AM     0      3593    9.80    0.98    0.00    0.00   10.78     2  kube-apiserver
10:03:39 AM     0      3870    0.98    0.98    0.00    0.00    1.96     0  etcd
10:03:39 AM     0      4040   12.75    7.84    0.00    0.00   20.59     0  kubelet
10:03:39 AM     0      4651    3.92    0.98    0.00    0.00    4.90     2  kube-proxy
10:03:39 AM 10001      6486    0.98    0.00    0.00    0.00    0.98     0  metrics-server

...

Average:      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
Average:        0         1    0.98    0.98    0.00    0.00    1.96     -  systemd
Average:        0         8    0.00    0.98    0.00    0.98    0.98     -  rcu_sched
Average:      103       810    1.96    0.00    0.00    1.96    1.96     -  dbus-daemon
Average:        0       907    2.94    2.94    0.00    0.00    5.88     -  systemd-logind
Average:        0      2425    3.92    0.98    0.00    0.00    4.90     -  dockerd
Average:        0      3522    0.00    1.96    0.00    0.00    1.96     -  kube-controller
Average:        0      3593    9.80    0.98    0.00    0.00   10.78     -  kube-apiserver
Average:        0      3870    0.98    0.98    0.00    0.00    1.96     -  etcd
Average:        0      4040   12.75    7.84    0.00    0.00   20.59     -  kubelet
Average:        0      4651    3.92    0.98    0.00    0.00    4.90     -  kube-proxy
Average:    10001      6486    0.98    0.00    0.00    0.00    

cpu 使用率过高怎么办

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

通过 perf 分析cpu的性能问题

perf 以性能事件采样为基础,不仅可以分析系统的各种事件和内核性能,还可以用来分析指定应用程序的性能问题。

安装

1
2
3
4
# yum
$ yum install perf
# apt
$ sudo apt install linux-tools-generic

perf top

perf top ,类似于 top,它能够实时显示占用 CPU 时钟最多的函数或者指令,因此可以用来查找热点函数,使用界面如下所示:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
$ perf top
Samples: 583K of event 'cycles:ppp', Event count (approx.): 32449180472
Overhead  Shared Object                 Symbol
   4.71%  [kernel]                      [k] update_blocked_averages
   2.89%  [kernel]                      [k] do_syscall_64
   1.14%  [kernel]                      [k] __entry_trampoline_start
   1.13%  perf                          [.] hpp__sort_overhead
   1.07%  [kernel]                      [k] syscall_return_via_sysret
   1.04%  [kernel]                      [k] cleanup_module
   1.00%  [kernel]                      [k] update_load_avg
   0.83%  perf                          [.] __hists__insert_output_entry
   0.76%  perf                          [.] rb_next
   0.68%  [kernel]                      [k] seccomp_run_filters
   0.62%  perf                          [.] perf_hpp__is_dynamic_entry
   0.55%  [kernel]                      [k] copy_page
   0.54%  [kernel]                      [k] __schedule
   0.54%  dockerd                       [.] runtime.scanobject

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

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

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

  • 第一列 Overhead ,是该符号的性能事件在所有采样中的比例,用百分比来表示。

  • 第二列 Shared ,是该函数或指令所在的动态共享对象(Dynamic Shared Object), 如内核、进程名、动态链接库名、内核模块名等。

  • 第三列 Object ,是动态共享对象的类型。比如 [.] 表示用户空间的可执行程序、或者动态链接库,而 [k] 则表示内核空间。

  • 最后一列 Symbol 是符号名,也就是函数名。当函数名未知时,用十六进制的地址来表示。

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

perf record & perf report

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

1
2
3
4
5
$ 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 参数,开启调用关系的采样,方便我们根据调用链来分析性能问题。

perf 其它使用

1
2
3
perf top -g -p $pid

perf record -ag -- sleep 2;perf report

ab

1
2
# 并发 10 个请求测试 Nginx 性能, 总共测试 100 个请求 
$ ab -c 10 -n 100 http://192.168.0.10:10000/

小结

  • 用户 CPU 和 Nice CPU 高,说明用户态进程占用了较多的 CPU,所以应该着重排查进 程的性能问题。

  • 系统 CPU 高,说明内核态占用了较多的 CPU,所以应该着重排查内核线程或者系统调 用的性能问题。

  • I/O 等待 CPU 高,说明等待 I/O 的时间比较长,所以应该着重排查系统存储是不是出现 了 I/O 问题。

  • 软中断和硬中断高,说明软中断或硬中断的处理程序占用了较多的 CPU,所以应该着重 排查内核中的中断服务程序。

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

短时应用的运行时间比较短,很难在 top 或者 ps 这类展示系统概要和进程快照的工具中 发现,你需要使用记录事件的工具来配合诊断,比如 execsnoop 或者 perf top。

常见分析工具perf-tools 及相关例子

Share on

tux
WRITTEN BY
tux
devops

What's on this Page