[转帖]《Linux性能优化实战》笔记(23)—— 内核线程 CPU 利用率过高,perf 与 火焰图
在排查网络问题时,我们还经常碰到的一个问题,就是内核线程的 CPU 使用率很高。比如,在高并发的场景中,内核线程 ksoftirqd 的 CPU 使用率通常就会比较高。回顾一下前面学过的 CPU 和网络模块,你应该知道,这是网络收发的软中断导致的。
要分析 ksoftirqd 这类 CPU 使用率比较高的内核线程,如果用前面介绍过的那些分析方法,一般需要借助于其他性能工具,进行辅助分析,并不算快捷。有没有其他更简单的方法,可以直接观察内核线程的行为,更快定位瓶颈呢?今天,我就继续以 ksoftirqd 为例,带你一起看看,如何分析内核线程的性能问题。
一、 内核线程
既然要讲内核线程的性能问题,我们就先来看看,有哪些常见的内核线程。
我们知道,在 Linux 中,用户态进程的“祖先”,都是 PID 号为 1 的 init 进程。现在主流的 Linux 发行版中,init 都是 systemd 进程;而其他的用户态进程,会通过systemd 来进行管理。
Linux 在启动过程中,有三个特殊的进程,也就是 PID 号最小的三个进程:
- 0 号进程为 idle 进程,这也是系统创建的第一个进程,它在初始化 1 号和 2 号进程后,演变为空闲任务。当 CPU 上没有其他任务执行时,就会运行它。
- 1 号进程为 init 进程,通常是 systemd 进程,在用户态运行,用来管理其他用户态进程。
- 2 号进程为 kthreadd 进程,在内核态运行,用来管理内核线程。
所以,要查找内核线程,我们只需要从 2 号进程开始,查找它的子孙进程即可。比如,你可以使用 ps 命令,来查找 kthreadd 的子进程:
-
ps -f --ppid 2 -p 2
-
-
UID PID PPID C STIME TTY TIME CMD
-
root 2 0 0 12:02 ? 00:00:01 [kthreadd]
-
root 9 2 0 12:02 ? 00:00:21 [ksoftirqd/0]
-
root 10 2 0 12:02 ? 00:11:47 [rcu_sched]
-
root 11 2 0 12:02 ? 00:00:18 [migration/0]
-
...
-
root 11094 2 0 14:20 ? 00:00:00 [kworker/1:0-eve]
-
root 11647 2 0 14:27 ? 00:00:00 [kworker/0:2-cgr]
从上面的输出,你能够看到,内核线程的名称(CMD)都在中括号里,所以,更简单的方法,就是直接查找名称包含中括号的进程。比如
-
ps -ef | grep "\[.*\]"
-
-
root 2 0 0 08:14 ? 00:00:00 [kthreadd]
-
root 3 2 0 08:14 ? 00:00:00 [rcu_gp]
-
root 4 2 0 08:14 ? 00:00:00 [rcu_par_gp]
-
...
了解内核线程的基本功能,对我们排查问题有非常大的帮助。比如,我们曾经在软中断案例中提到过 ksoftirqd。它是一个用来处理软中断的内核线程,并且每个 CPU 上都有一个。如果你知道这一点,那么以后遇到 ksoftirqd 的 CPU 使用高的情况,就会首先怀疑是软中断的问题,然后从软中断的角度来进一步分析。
其实,除了刚才看到的 kthreadd 和 ksoftirqd 外,还有很多常见的内核线程,我们在性能分析中都经常会碰到,比如下面这几个内核线程:
- kswapd0:用于内存回收(swap)
- kworker:用于执行内核工作队列,分为绑定 CPU和未绑定 CPU两类。
- migration:在负载均衡过程中把进程迁移到 CPU 上,每个 CPU 都有一个migration 内核线程。
- jbd2/sda1-8:jbd 是 Journaling Block Device 的缩写,用来为文件系统提供日志功能,以保证数据的完整性;名称中的 sda1-8,表示磁盘分区名称和设备号。每个使用了ext4 文件系统的磁盘分区,都会有一个 jbd2 内核线程。
- pdflush:用于将内存中的脏页写入磁盘(已经在 3.10 中合并入了 kworker 中)。
二、 案例分析
运行 hping3 命令,模拟 Nginx 的客户端请求:
-
# -S参数表示设置TCP协议的SYN(同步序列号),-p表示目的端口为80
-
# -i u10表示每隔10微秒发送一个网络帧
-
# 注:如果你在实践过程中现象不明显,可以尝试把10调小,比如调成5甚至1
-
hping3 -S -p 80 -i u10 192.168.0.30
你会发现192.168.0.30服务器的系统响应明显变慢了。我们不妨执行 top,观察一下系统和进程的 CPU 使用情况:
-
$ top
-
top - 08:31:43 up 17 min, 1 user, load average: 0.00, 0.00, 0.02
-
Tasks: 128 total, 1 running, 69 sleeping, 0 stopped, 0 zombie
-
%Cpu0 : 0.3 us, 0.3 sy, 0.0 ni, 66.8 id, 0.3 wa, 0.0 hi, 32.4 si, 0.0 st
-
%Cpu1 : 0.0 us, 0.3 sy, 0.0 ni, 65.2 id, 0.0 wa, 0.0 hi, 34.5 si, 0.0 st
-
KiB Mem : 8167040 total, 7234236 free, 358976 used, 573828 buff/cache
-
KiB Swap: 0 total, 0 free, 0 used. 7560460 avail Mem
-
-
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
-
9 root 20 0 0 0 0 S 7.0 0.0 0:00.48 ksoftirqd/0
-
18 root 20 0 0 0 0 S 6.9 0.0 0:00.56 ksoftirqd/1
-
2489 root 20 0 876896 38408 21520 S 0.3 0.5 0:01.50 docker-containe
-
3008 root 20 0 44536 3936 3304 R 0.3 0.0 0:00.09 top
-
1 root 20 0 78116 9000 6432 S 0.0 0.1 0:11.77 systemd
可以看到,两个 CPU 的软中断使用率都超过了 30%,而 CPU 使用率最高的进程是软中断内核线程 ksoftirqd/0 和 1。
虽然我们已经知道了 ksoftirqd 的基本功能,可以猜测是因为大量网络收发,引起了CPU 使用率升高;但它到底在执行什么逻辑,我们却并不知道。对于普通进程,我们要观察其行为有很多方法,比如 strace、pstack、lsof 等等。但这些工具并不适合内核线程。如果用 pstack 或者通过 /proc/pid/stack 查看ksoftirqd/0(进程号为 9)的调用栈,分别可以得到以下输出:
-
$ pstack 9
-
Could not attach to target 9: Operation not permitted.
-
detach: No such process
-
$ cat /proc/9/stack
-
[<0>] smpboot_thread_fn+0x166/0x170
-
[<0>] kthread+0x121/0x140
-
[<0>] ret_from_fork+0x35/0x40
-
[<0>] 0xffffffffffffffff
pstack 报出的是不允许挂载进程的错误;而 /proc/9/stack 方式虽然有输出,但输出中并没有详细的调用栈情况。那还有没有其他方法,来观察内核线程 ksoftirqd 的行为呢?
既然是内核线程,自然应该用到内核中提供的机制。我想你肯定还记得 perf 这个内核自带的性能剖析工具。perf 可以对指定的进程或者事件进行采样,并且还可以用调用栈的形式,输出整个调用链上的汇总信息。 不妨就用 perf ,来试着分析一下进程号为 9 的 ksoftirqd。
执行下面的 perf record 命令;并指定进程号 9 ,以便记录 ksoftirqd 的行为。
-
# 采样30s后退出
-
perf record -a -g -p 9 -- sleep 30
稍等一会儿,在上述命令结束后,继续执行 perf report命令,就可以得到 perf 的汇总报告。按上下方向键以及回车键,展开比例最高的 ksoftirqd 后,可以得到下面这个调用关系链图:
从这个图中,你可以清楚看到 ksoftirqd 执行最多的调用过程。虽然你可能不太熟悉内核源码,但通过这些函数,我们可以大致看出它的调用栈过程:
- net_rx_action 和 netif_receive_skb,表明这是接收网络包(rx 表示 receive)。
- br_handle_frame ,表明网络包经过了网桥(br 表示 bridge)。
- br_nf_pre_routing ,表明在网桥上执行了 netfilter 的 PREROUTING(nf 表示netfilter),而我们已经知道 PREROUTING 主要用来执行 DNAT,所以可以猜测这里有 DNAT 发生。
- br_pass_frame_up,表明网桥处理后,再交给桥接的其他桥接网卡进一步处理。比如,在新的网卡上接收网络包、执行 netfilter 过滤规则等等
我们的猜测对不对呢?实际上,我们案例最开始用 Docker 启动了容器,而 Docker 会自动为容器创建虚拟网卡、桥接到 docker0 网桥并配置 NAT 规则。这一过程,如下图所示
当然了,前面 perf report 界面的调用链还可以继续展开。但很不幸,我的屏幕不够大,如果展开更多的层级,最后几个层级会超出屏幕范围。这样,即使我们能看到大部分的调用过程,却也不能说明后面层级就没问题。那么,有没有更好的方法,来查看整个调用栈的信息呢?
三、 火焰图
1. 简介
针对 perf 汇总数据的展示问题,Brendan Gragg 发明了火焰图,通过矢量图的形式,更直观展示汇总结果。下图就是一个针对 mysql 的火焰图示例。
- 横轴表示采样数和采样比例。一个函数占用的横轴越宽代表它的执行时间越长。同一层的多个函数,则是按照字母来排序。
- 纵轴表示调用栈,由下往上根据调用关系逐个展开。换句话说,上下相邻的两个函数中,下面的函数,是上面函数的父函数。调用栈越深,纵轴就越高。
- 图中的颜色并没有特殊含义,只是用来区分不同的函数。
火焰图是动态的矢量图格式,所以它还支持一些动态特性。比如,鼠标悬停到某个函数上时,就会自动显示这个函数的采样数和采样比例。而当你用鼠标点击函数时,火焰图就会把该层及其上的各层放大,方便观察细节。上面 mysql 火焰图的示例,就表示了 CPU 的繁忙情况,这种火焰图也被称为 on-CPU 火焰图。
如果我们根据性能分析的目标来划分,火焰图可以分为下面这几种。
- on-CPU 火焰图:表示 CPU 的繁忙情况,用在 CPU 使用率比较高的场景中。
- off-CPU 火焰图:表示 CPU 等待 I/O、锁等各种资源的阻塞情况。
- 内存火焰图:表示内存的分配和释放情况。
- 热 / 冷火焰图:表示将 on-CPU 和 off-CPU 结合在一起综合展示。
- 差分火焰图:表示两个火焰图的差分情况,红色表示增长,蓝色表示衰减。常用来比较不同场景和不同时期的火焰图,以便分析系统变化前后对性能的影响情况。
接下来,我们再回到案例,运用火焰图来观察刚才perf record 得到的记录。
2. 生成火焰图
我们先下载几个能从 perf record 记录生成火焰图的工具,这些工具都放在 https://github.com/brendangregg/FlameGraph 上面。你可以执行下面的命令来下载:
-
git clone https://github.com/brendangregg/FlameGraph
-
cd FlameGraph
安装好工具后,要生成火焰图,其实主要需要三个步骤:
- 执行 perf script ,将 perf record 的记录转换成可读的采样记录;
- 执行 stackcollapse-perf.pl 脚本,合并调用栈信息;
- 执行 flamegraph.pl 脚本,生成火焰图
在 Linux 中,我们可以使用管道,来简化这三个步骤的执行过程。假设刚才用 perf record 生成的文件路径为 /root/perf.data,执行下面的命令,你就可以直接生成火焰图:
perf script -i /root/perf.data | ./stackcollapse-perf.pl --all | ./flamegraph.pl > ksoftirqd.svg
执行成功后,使用浏览器打开 ksoftirqd.svg ,你就可以看到生成的火焰图了。
3. 分析火焰图
根据刚刚讲过的火焰图原理,这个图应该从下往上看,沿着调用栈中最宽的函数来分析执行次数最多的函数。这儿看到的结果,其实跟刚才的 perf report 类似,但直观了很多,中间这一团火,很明显就是最需要我们关注的地方。我们顺着调用栈由下往上看(顺着图中蓝色箭头),就可以得到跟刚才 perf report 中一样的结果:
- 最开始,还是 net_rx_action 到 netif_receive_skb 处理网络收包;
- 然后, br_handle_frame 到 br_nf_pre_routing ,在网桥中接收并执行 netfilter 钩子函数;
- 再向上, br_pass_frame_up 到 netif_receive_skb ,从网桥转到其他网络设备又一次接收。
- 不过最后,到了 ip_forward 这里,已经看不清函数名称了。所以我们需要点击ip_forward,展开最上面这一块调用栈:
这样,就可以进一步看到 ip_forward 后的行为,也就是把网络包发送出去。根据这个调用过程,再结合我们前面学习的网络收发和 TCP/IP 协议栈原理,这个流程中的网络接收、网桥以及 netfilter 调用等,都是导致软中断 CPU 升高的重要因素,也就是影响网络性能的潜在瓶颈。
不过,回想一下网络收发的流程,你可能会觉得它缺了好多步骤。比如,这个堆栈中并没有 TCP 相关的调用,也没有连接跟踪 conntrack 相关的函数。实际上,这些流程都在其他更小的火焰中,你可以点击上图左上角的“Reset Zoom”,回到完
整火焰图中,再去查看其他小火焰的堆栈。
所以,在理解这个调用栈时要注意。从任何一个点出发、纵向来看的整个调用栈,其实只是最顶端那一个函数的调用堆栈,而非完整的内核网络执行流程。
另外,整个火焰图不包含任何时间的因素,所以并不能看出横向各个函数的执行次序。到这里,我们就找出了内核线程 ksoftirqd 执行最频繁的函数调用堆栈,而这个堆栈中的各层级函数,就是潜在的性能瓶颈来源。这样,后面想要进一步分析、优化时,也就有了根据。
[转帖]《Linux性能优化实战》笔记(23)—— 内核线程 CPU 利用率过高,perf 与 火焰图的更多相关文章
- Linux性能优化实战学习笔记:第五十八讲
一.上节回顾 专栏更新至今,咱们专栏最后一部分——综合案例模块也要告一段落了.很高兴看到你没有掉队,仍然在积极学习思考.实践操作,并热情地分享你在实际环境中,遇到过的各种性能问题的分析思路以及优化方法 ...
- 深挖计算机基础:Linux性能优化学习笔记
参考极客时间专栏<Linux性能优化实战>学习笔记 一.CPU性能:13讲 Linux性能优化实战学习笔记:第二讲 Linux性能优化实战学习笔记:第三讲 Linux性能优化实战学习笔记: ...
- Linux性能优化实战学习笔记:第五十二讲
一.上节回顾 上一节,我们一起学习了怎么使用动态追踪来观察应用程序和内核的行为.先简单来回顾一下.所谓动态追踪,就是在系统或者应用程序还在正常运行的时候,通过内核中提供的探针,来动态追踪它们的行为,从 ...
- Linux性能优化实战学习笔记:第四十九讲
一.上节回顾 上一期,我们一起梳理了,网络时不时丢包的分析定位和优化方法.先简单回顾一下.网络丢包,通常会带来严重的性能下降,特别是对 TCP 来说,丢包通常意味着网络拥塞和重传,进而会导致网络延迟增 ...
- Linux性能优化实战学习笔记:第五十讲
一.上节回顾 上一节,我以 ksoftirqd CPU 使用率高的问题为例,带你一起学习了内核线程 CPU 使用率高时的分析方法.先简单回顾一下. 当碰到内核线程的资源使用异常时,很多常用的进程级性能 ...
- Linux性能优化实战学习笔记:第五十五讲
一.上节回顾 上一节,我们一起学习了,应用程序监控的基本思路,先简单回顾一下.应用程序的监控,可以分为指标监控和日志监控两大块. 指标监控,主要是对一定时间段内的性能指标进行测量,然后再通过时间序列的 ...
- Linux性能优化实战学习笔记:第五十一讲
一.上节回顾 上一节,我带你一起学习了常见的动态追踪方法.所谓动态追踪,就是在系统或者应用程序正常运行的时候,通过内核中提供的探针,来动态追踪它们的行为,从而辅助排查出性能问题的瓶颈. 使用动态追踪, ...
- 《Linux 性能优化实战—倪朋飞 》学习笔记 CPU 篇
平均负载 指单位时间内,系统处于可运行状态和不可中断状态的平均进程数,即平均活跃进程数 可运行状态:正在使用CPU或者正在等待CPU 的进程,也就是我们常用 ps 命令看到的,处于 R 状态 (Run ...
- Linux性能优化实战学习笔记:第二十七讲
一.案例环境描述 1.环境准备 2CPU,4GB内存 预先安装docker sysstat工具 2.温馨提示 案例中 Python 应用的核心逻辑比较简单,你可能一眼就能看出问题,但实际生产环境中的源 ...
- Linux性能优化实战学习笔记:第三十一讲
一.上节回顾 上一节,我们一起回顾了常见的文件系统和磁盘 I/O 性能指标,梳理了核心的 I/O 性能观测工具,最后还总结了快速分析 I/O 性能问题的思路. 虽然 I/O 的性能指标很多,相应的性能 ...
随机推荐
- [ACTF2020 新生赛]Exec 1
[ACTF2020 新生赛]Exec 1 审题 发现题目有ping功能,猜测是命令执行漏洞. 知识点 linux系统命令 解题 先ping127.0.0.1,观察是否正常执行. 发现正常后执行ls / ...
- Winform PictureBox图片旋转
Image img = this.pictureBox1.Image; img.RotateFlip(RotateFlipType.Rotate90FlipNone); this.pictureBox ...
- Spring表达式语言(SPEL)学习(02)
构造数组 /** * 数组生成 */ @Test public void test5(){ int[] numbers1 = (int[]) parser.parseExpression(" ...
- Spring源码学习笔记6——Spring bean的实例化
一丶前言 前面我们了解到读取xml or 根据扫描路径生成BeanDefinition并注册到BeanFactory,相当于我们具备了生火做饭的原材料:BeanDefinition,接下来就是Spri ...
- 理解三值逻辑与NULL,你离SQL高手更近了一步
什么是NULL NULL 用于表示缺失的值或遗漏的未知数据,不是某种具体类型的值.数据表中的 NULL 值表示该值所处的字段为空,值为 NULL 的字段没有值,尤其要明白的是:NULL 值与 0 或者 ...
- 案例展示自定义C函数的实现过程
摘要:用户在使用数据库过程中,受限于内置函数的功能,部分业务不易实现时,可以使用自定义C函数实现特殊功能.本文通过两个示例展示自定义C函数的实现过程. 前言 用户在使用数据库过程中,常常受限于内置函数 ...
- 从零开始学习python | 实例讲解如何制作Python模式程序
摘要:在本文中,我们将学习python中的各种模式程序. Python编程语言很容易学习.易于语法实现的各种库使其脱颖而出,这是它成为本世纪最流行的编程语言的众多原因之一.虽然学习很容易,但访问员通常 ...
- 云图说|OLAP开源引擎的一匹黑马,MRS集群组件之ClickHouse
摘要:ClickHouse是俄罗斯公司Yandex在2016年开源的高性能.开源联机分析列式数据库管理系统.开源后,凭借卓越的分析性能.极好的线性扩展能力和丰富的功能,被业界公认为实时分析领域OLAP ...
- 跟我读论文丨ACL2021 NER BERT化隐马尔可夫模型用于多源弱监督命名实体识别
摘要:本文是对ACL2021 NER BERT化隐马尔可夫模型用于多源弱监督命名实体识别这一论文工作进行初步解读. 本文分享自华为云社区<ACL2021 NER | BERT化隐马尔可夫模型用于 ...
- 一文讲述G6实现流程图绘制的常用方法
摘要:G6 是一个图可视化引擎.它提供了图的绘制.布局.分析.交互.动画等图可视化的基础能力. 本文分享自华为云社区<会用这些的api,轻松绘制流程图--antv.g6流程图入门>,作者: ...