Linux 内核技术实战课
邵亚方
前蘑菇街技术专家,Linux Kernel 活跃贡献者
23704 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 26 讲
Linux 内核技术实战课
15
15
1.0x
00:00/00:00
登录|注册

20 分析篇 | 如何分析CPU利用率飙高问题 ?

追踪者处理系统调用
SIGTRAP信号
ptrace系统调用
跟踪特定系统调用和执行时间
分析应用执行逻辑和内核逻辑
追踪进程的系统调用
遍历inode查看Page Cache组成
inode和Page Cache关系
观察I/O行为
观察磁盘I/O情况
function_graph功能
/proc/kallsyms
追踪系统调用耗时
function_trace功能
工作原理
strace
Page Cache观测
iotop
iostat
追踪系统调用
查看系统调用对应的内核函数
ftrace
系统调用
自己写分析工具
分析工具
内核开发者常用分析工具
拓展分析边界
如何分析CPU利用率飙高问题

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

你好,我是邵亚方。
如果你是一名应用开发者,那你应该知道如何去分析应用逻辑,对于如何优化应用代码提升系统性能也应该有自己的一套经验。而我们这节课想要讨论的是,如何拓展你的边界,让你能够分析代码之外的模块,以及对你而言几乎是黑盒的 Linux 内核。
在很多情况下,应用的性能问题都需要通过分析内核行为来解决,因此,内核提供了非常多的指标供应用程序参考。当应用出现问题时,我们可以查看到底是哪些指标出现了异常,然后再做进一步分析。不过,这些内核导出的指标并不能覆盖所有的场景,我们面临的问题可能更加棘手:应用出现性能问题,可是系统中所有的指标都看起来没有异常。相信很多人都为此抓狂过。那出现这种情况时,内核到底有没有问题呢,它究竟在搞什么鬼?这节课我就带你探讨一下如何分析这类问题。
我们知道,对于应用开发者而言,应用程序的边界是系统调用,进入到系统调用中就是 Linux 内核了。所以,要想拓展分析问题的边界,你首先需要知道该怎么去分析应用程序使用的系统调用函数。对于内核开发者而言,边界同样是系统调用,系统调用之外是应用程序。如果内核开发者想要拓展分析问题的边界,也需要知道如何利用系统调用去追踪应用程序的逻辑。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文详细介绍了如何分析CPU利用率飙高问题,并提供了解决问题的方法。作者首先强调了拓展分析问题边界的重要性,指出应用开发者需要了解如何分析应用程序使用的系统调用函数,而内核开发者则需要知道如何利用系统调用去追踪应用程序的逻辑。文章提到了strace工具的原理和使用方法,以及使用ftrace工具来追踪系统调用的内核函数。通过实际案例,作者展示了如何使用ftrace的function_trace功能来追踪系统调用的耗时情况。此外,文章还介绍了如何观测Page Cache的行为以及自己编写分析工具的方法。总的来说,本文强调了对系统调用的分析和追踪的重要性,以及如何利用工具来解决CPU利用率飙高的问题。对于读者来说,本文提供了丰富的技术知识和实用的分析方法,有助于他们更好地理解和解决类似的CPU利用率飙高问题。

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

全部留言(9)

  • 最新
  • 精选
  • Linuxer
    邵老师,你好,有个负载高的问题,我判断是因为开的线程数过多导致的,我想请教一下是下面的这些数据是不是有说服力或者有什么手段进一步确认? 谢谢! top top - 18:46:33 up 186 days, 4:31, 3 users, load average: 67.47, 55.78, 61.19 Tasks: 377 total, 1 running, 376 sleeping, 0 stopped, 0 zombie %Cpu(s): 51.0 us, 30.2 sy, 0.0 ni, 8.0 id, 0.0 wa, 0.0 hi, 10.8 si, 0.0 st KiB Mem : 13173332+total, 21147572 free, 6840020 used, 10374573+buff/cache grep procs_running /proc/stat procs_running 70 grep procs_running /proc/stat procs_running 90 grep procs_running /proc/stat procs_running 119 perf top -U 4.41% [kernel] [k] system_call_after_swapgs 3.49% [kernel] [k] do_select 3.23% [kernel] [k] copy_user_enhanced_fast_string 2.98% [kernel] [k] sysret_check 2.78% [kernel] [k] __schedule 1.82% [kernel] [k] __check_object_size 1.67% [kernel] [k] fget_light 1.22% [kernel] [k] tcp_ack 1.21% [kernel] [k] __audit_syscall_exit 1.16% [kernel] [k] __x86_indirect_thunk_rax 1.15% [kernel] [k] tcp_poll 1.13% [kernel] [k] _raw_spin_lock_irqsave 1.12% [kernel] [k] __switch_to perf stat Performance counter stats for 'system wide': 376801.028719 cpu-clock (msec) # 31.997 CPUs utilized 7,323,807 context-switches # 0.019 M/sec 824,699 cpu-migrations # 0.002 M/sec 100,337 page-faults # 0.266 K/sec 808,730,622,944 cycles # 2.146 GHz 429,965,110,114 instructions # 0.53 insn per cycle 90,908,416,046 branches # 241.264 M/sec 2,554,107,830 branch-misses # 2.81% of all branches 11.776125779 seconds time elapsed

    作者回复: 从你提供的top信息来看,此时的cpu利用率已经很高了: %Cpu(s): 51.0 us, 30.2 sy, 0.0 ni, 8.0 id, 0.0 wa, 0.0 hi, 10.8 si, 0.0 st 51.0 us, 30.2 sy, 10.8 si 加起来有90%,这么高的cpu利用率和running的线程数太多有关系,需要将cpu利用率降下来。另外你可以看到,有30%的sys和10%的si,看起来是网卡软中断太多导致的,可能你的系统里存在非常多的网络连接,如果是这样的话,需要去评估下是否有必要控制连接数。 ss -s可以查看系统里连接数统计信息。 从perf热点: 3.49% [kernel] [k] do_select select(2)系统调用是个热点,也跟网络连接较多或者网络请求较多有关系。

    2020-11-06
    2
    10
  • 莫名
    推荐使用 ftrace 前端 trace-cmd,直接操作 tracefs 文件略显繁琐。

    作者回复: trace-cmd使用起来更简单些,但是它不灵活,很多时候需要根据实际情况来观测一些细节,这个时候就需要tracefs+手写Python进行分析了。 我个人不太喜欢使用tracep-cmd,我更喜欢用Python来写问题分析工具。

    2020-10-21
    2
    3
  • 我来也
    # 老师文中提到的`查看 Page Cache 的组成`这个功能,感觉很吸引人啊! # 根据老师的提示,也只找到了这两个方式: ## [Is it possible to list the files that are cached?](https://serverfault.com/a/782640) 原理也比较简单: 借助`ps`找出`rss`的top10进程,然后根据`lsof`找出进程引用的文件,最后借助`linux-fincore`查看这些文件在PageCache中的信息. 感觉这个脚本也有局限性. 由于`linux-fincore`只能查看列出的文件,所以是无法查看已经不被进程占用的`Page Cache`中的文件及大小的. ## [pcstat](https://github.com/tobert/pcstat) 这个工具是借助`mincore`来查看的Page Cache信息,但是也是需要列出具体的文件名. # 疑问 还是老师的这个方法好,不需要提供文件列表,也可以查看内存中都有哪些文件以及这些文件的大小. 请问,老师的这个工具有开源版本么?

    作者回复: 这个方法需要修改内核来实现,或者写一个内核模块来实现。 主要思路我已经写在文章里了,你可以思考下如何来实现。

    2020-10-03
    3
  • 会飞的鱼
    老师好,我的服务器内核空间的cpu使用率达到了100%,重启了几次依然没有解决,然后我用top查看,没有发现cpu占用很高的进程,用execsnoop也没发现异常,然后用pidstat -w查看,发现rcu_sched的上下文切换很频繁,而且是自愿上下文切换,然后我再用perf top -g -p 9追踪,发现有schedule,finish_task_switch等系统调用,但我还是不清楚是什么原因导致的内核空间cpu使用率高,服务器上也没跑什么程序,这种情况怎么进一步解决呢? 可以加您微信进一步求教下吗?

    作者回复: cpu的利用率是100%,能否细化一下具体是什么的利用率高,比如usr,sys,wait,siq等?top就可以看到。明确了哪一项高后,就可以针对性的分析了。 你可以把观察到的具体现象发到我邮箱:laoar.shao@gmail.com, 我在开篇词里也有提到我的邮箱。

    2020-11-25
    2
  • Geek_9bf0b0
    邵老师,关于在 sysrq 里实现显示出系统中所有 R 和 D 状态的任务的功能,我的想法是将 show_state_filter()接口的state_filter参数改成指针类型,传递参数NULL时表示显示所有进程信息, 这样避免与TASK_RUNNING冲突,代码修改量也小,也相对优雅。 -extern void show_state_filter(unsigned long state_filter); +extern void show_state_filter(unsigned long *state_filter); static inline void show_state(void) { - show_state_filter(0); + show_state_filter(NULL); } static void sysrq_handle_showstate_blocked(int key) { - show_state_filter(TASK_UNINTERRUPTIBLE); + unsigned long filter = TASK_UNINTERRUPTIBLE; + + show_state_filter(&filter); } 然后调用unregister_sysrq_key()移除sysrq_showstate_blocked_op, 接着register_sysrq_key()接口注册定制化的op, 定制化的回调函数handle可以实现如下: static void sysrq_handle_showstate_load(int key) { unsigned long filter; filter = TASK_RUNNING; show_state_filter(&filter); filter = TASK_UNINTERRUPTIBLE; show_state_filter(&filter); } 关于注册定制化的sysrq,可以通过early_param或者模块的方式。 以模块的方式注册定制化的sysrq时需要导出内核符号show_state_filter。

    作者回复: filter = TASK_RUNNING; show_state_filter(&filter); filter = TASK_UNINTERRUPTIBLE; show_state_filter(&filter); 这里调用两次看起来不太好,因为每次都要检查所有task,效率低。最好只调用一次,比如以(TASK_UNINTERRUPTIBLE | TASK_RUNNING)的方式来调用。

    2020-10-10
    1
  • nestle
    老是,IO排队是不是应该看avgqu-sz这个字段?

    作者回复: 对的 它表示队列长度

    2021-06-14
  • 莫名
    iotop 没有发现写 I/O 的用户进程,觉得可以往上走,在文件系统层面做些分析,page 紧张的情况下,文件读写操作会变得相对慢一些。借助 BCC 现有工具 ext4slower、ext4dist(假设是 ext4 fs)分析,应该可以看到具体的用户进程。
    2022-03-17
    1
  • Wade_阿伟
    我是一名系统运维工程师,对内核还不太了解。但感觉这节课还是收货了很多,尤其是如何借助ftrace去做进一步分析,以及如何查看page cache中都是哪些文件及文件大小。之前只知道使用cachestat和cachetop去查看缓存命中情况。希望以后工作中能够运用上。
    2021-10-24
    1
  • Bin
    你好,邵老师, 这篇文文章标题写的 cpu利用率高因为系统调用的问题,而这个系统调用主要卡在io wait上,但io wait 跟cpu利用率没关系吧,cpu利用率(用户态加系统态)应该不受影响才对
    2023-01-09归属地:广东
    1
收起评论
显示
设置
留言
9
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部