Linux 性能优化实战
倪朋飞
资深 Linux 专家,Kubernetes 项目维护者
87258 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 65 讲
结束语 (1讲)
Linux 性能优化实战
15
15
1.0x
00:00/00:00
登录|注册

49 | 案例篇:内核线程 CPU 利用率太高,我该怎么办?

火焰图分析
生成火焰图
perf report
perf record
观察系统和进程的 CPU 使用情况
使用 hping3 模拟客户端请求
使用 curl 访问 Nginx 监听的端口
Nginx 应用运行
安装必要工具
机器配置
pdflush
jbd2/sda1-8
migration
kworker
kswapd0
ksoftirqd
2 号进程为 kthreadd 进程
1 号进程为 init 进程
0 号进程为 idle 进程
PID 号为 1 的 init 进程
差分火焰图
热/冷火焰图
内存火焰图
off-CPU 火焰图
on-CPU 火焰图
火焰图分析
perf 工具分析
案例分析
案例准备
常见的内核线程
内核线程
思考
火焰图优化
内核线程 CPU 利用率过高
性能优化方法
性能问题分析
性能问题分析与优化方法

该思维导图由 AI 生成,仅供参考

你好,我是倪朋飞。
上一期,我们一起梳理了,网络时不时丢包的分析定位和优化方法。先简单回顾一下。
网络丢包,通常会带来严重的性能下降,特别是对 TCP 来说,丢包通常意味着网络拥塞和重传,进而会导致网络延迟增大以及吞吐量降低。
而分析丢包问题,还是用我们的老套路,从 Linux 网络收发的流程入手,结合 TCP/IP 协议栈的原理来逐层分析。
其实,在排查网络问题时,我们还经常碰到的一个问题,就是内核线程的 CPU 使用率很高。比如,在高并发的场景中,内核线程 ksoftirqd 的 CPU 使用率通常就会比较高。回顾一下前面学过的 CPU 和网络模块,你应该知道,这是网络收发的软中断导致的。
而要分析 ksoftirqd 这类 CPU 使用率比较高的内核线程,如果用我前面介绍过的那些分析方法,你一般需要借助于其他性能工具,进行辅助分析。
比如,还是以 ksoftirqd 为例,如果你怀疑是网络问题,就可以用 sar、tcpdump 等分析网络流量,进一步确认网络问题的根源。
不过,显然,这种方法在实际操作中需要步骤比较多,可能并不算快捷。你肯定也很想知道,有没有其他更简单的方法,可以直接观察内核线程的行为,更快定位瓶颈呢?
今天,我就继续以 ksoftirqd 为例,带你一起看看,如何分析内核线程的性能问题。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入介绍了解决内核线程 CPU 利用率过高的方法,通过详细讲解内核线程的性能问题分析和案例分析,帮助读者快速了解解决内核线程 CPU 利用率过高的方法。文章介绍了使用 perf 工具来分析内核线程的行为,并详细解释了火焰图的含义和查看方法。通过实例操作,演示了如何生成火焰图以及如何分析火焰图中的热点函数,帮助读者更好地理解和解决内核线程性能问题。此外,作者还分享了在分析内核线程性能问题时的思考和经验,并邀请读者分享交流。整篇文章通过实用的技术方法和案例分析,为读者提供了解决内核线程性能问题的实用指南。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Linux 性能优化实战》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(20)

  • 最新
  • 精选
  • 李逍遥
    老师,能讲讲内存火焰图生成perf.data数据时,perf record加哪些选项吗?

    作者回复: 要加上内存管理相关的事件(函数),比如perf record -e syscalls:sys_enter_mmap -a -g -- sleep 60

    2019-04-03
    9
  • 李逍遥
    cpu火焰图和内存火焰图,在生成数据时有什么不同?

    作者回复: 火焰图的结构是一样的,只是函数堆栈不一样,内存火焰图侧重于内存管理函数的调用栈

    2019-04-01
    9
  • 青石
    两周时间,终于追上来了。 请问老师,有哪些书有助于通过内核函数来定位故障,Linux用了9年,看到这还是感觉有些吃力。 内核线程问题,我的环境和老师的有些区别,没有br_nf_pre_routing函数调用,但是从ip_forward推测与消息转发有关,sar发现有大量小包接收,conntrack -L看到大量本机到docker地址的SYN_SENT状态的连接、hping3服务器到测试服务器的SYN_RECV状态连接。初步定位到具体的docker。 上面思考的过程,有点因为知道问题点,所以朝这个方向走的感觉。

    作者回复: 内核里面其实就提供了很多工具,可以参考下50和51篇中的动态追踪方法

    2019-03-22
    3
  • 请问有没有可以表示调用顺序的火焰图? 或者类似的其它图??? 感觉这样更有用阿

    作者回复: 可以用 ebpf 跟踪调用栈

    2022-02-05
    1
  • 2xshu
    老师,这是最后一节课程吗?

    作者回复: 不是,看原来的目录,还有好些篇

    2019-03-18
    1
  • 我来也
    [D49打卡] 之前用火焰图分析过golang程序的内存分配及cpu使用率情况.感觉非常直观.能快速找到瓶颈.

    作者回复: 嗯嗯 Go内置了pprof 工具,用起来更简单

    2019-03-18
    1
  • ninuxer
    打卡day52 有碰到一个内核问题,docker宿主机上kworker/u80进程的cpu占用率一直100%,其他的kworker进程都正常,每隔几个月就会碰到一次,为了快速恢复业务,就直接重启了,主要是没办法在线下实验的时候复现问题,所以就没有深入的分析,后面碰到后,可以用老师的方法,把perf record采集一段时间的调用信息,然后拿出去分析下👍

    作者回复: 嗯嗯

    2019-03-18
  • 安排
    横轴的长短代表执行时间长短,一个函数被调用多次那横轴很长,一个函数执行一次但是在里面休眠了,这算执行时间很长吗?on-cpu火焰图是不是只记录真正的在cpu上的执行时间而不把睡眠时间算在内?
    2020-01-27
    5
  • opdozz
    老师,最近碰到一个kworker内核进程问题,48C的服务器,docker宿主机, 某个kworker会占满两个CPU,一个sys跑满,另外一个iowait跑满,剩下的CPU都很空闲,但是业务处理很慢,重启之后就好了,但是过段时间又复发, 不规律。 perf收集了信息,__rpc_execute 这个调用占了很多,下层nfs4_xdr_enc_open调用也占了很多,和挂的nas存储有关系吗,但是存储那边排查没有任何问题。
    2021-07-09
    1
  • 行者
    很赞,准备回去用火焰图分析下我们后端服务。^ _ ^
    2019-03-19
    1
收起评论
显示
设置
留言
20
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部