06 | 案例篇:系统的 CPU 使用率很高,但为啥却找不到高 CPU 的应用?
该思维导图由 AI 生成,仅供参考
案例分析
你的准备
- 深入了解
- 翻译
- 解释
- 总结
本文通过一个 Nginx + PHP 的 Web 服务案例,探讨了高 CPU 使用率的排查方法。作者首先介绍了案例的准备工作,包括安装必要的工具和搭建测试环境。随后,作者详细讲解了在测试过程中使用的命令和工具,如 docker、ab、top 和 pidstat,并展示了如何观察系统的 CPU 使用情况和分析进程的 CPU 使用情况。通过实际操作和分析,读者可以了解到在高 CPU 使用率的情况下,如何使用工具来定位问题,并发现了即使系统 CPU 使用率很高,但却找不到高 CPU 使用率的进程的情况。文章还介绍了如何使用 pstree 查找进程的父进程,以及通过查看应用源码来分析进程调用的情况。这篇文章对于希望深入了解系统性能分析和排查高 CPU 使用率问题的读者来说,提供了有益的实践经验和技术指导。文章还介绍了如何使用 pstree 查找进程的父进程,以及通过查看应用源码来分析进程调用的情况。文章还介绍了如何使用 pstree 查找进程的父进程,以及通过查看应用源码来分析进程调用的情况。
《Linux 性能优化实战》,新⼈⾸单¥68
全部留言(152)
- 最新
- 精选
- sotey对老师膜拜!今天一早生产tomcat夯住了,16颗cpu全部98%以上,使用老师的方法加上java的工具成功定位到了问题线程和问题函数。
作者回复: 举一反三动手实践的楷模😊 希望看到更多的人把这些思路用起来
2018-12-033169 - 好好学习perf record -ag -- sleep 2;perf report 一部到位
作者回复: 👍
2018-12-1073 - brucedinghttp://blog.bruceding.com/420.html 这个是之前的优化经历,通过 perf + 火焰图,定位热点代码,结合业务和网络分析,最终确定问题原因
作者回复: 赞,再加上APM定位就更简单了
2019-02-11243 - 风老师好,我在实验的过程中,在最后使用 perf record -ag 的时候,发现记录下来的值,其中 stress 并不是消耗 CPU 最猛的进程,而是swapper,不知道什么原因?碰到这种情况时,该如何继续排查下去?以下是我的 perf report Samples: 223K of event 'cpu-clock', Event count (approx.): 55956000000 Children Self Command Shared Object Symbol + 11.54% 0.00% swapper [kernel.kallsyms] [k] cpu_startup_entry + 11.42% 0.00% swapper [kernel.kallsyms] [k] default_idle_call + 11.42% 0.00% swapper [kernel.kallsyms] [k] arch_cpu_idle + 11.42% 0.00% swapper [kernel.kallsyms] [k] default_idle + 11.05% 11.05% swapper [kernel.kallsyms] [k] native_safe_halt + 8.69% 0.00% swapper [kernel.kallsyms] [k] start_secondary + 4.36% 4.36% stress libc-2.24.so [.] 0x0000000000036387 + 3.44% 0.00% php-fpm libc-2.24.so [.] 0xffff808406d432e1 + 3.44% 0.00% php-fpm [unknown] [k] 0x6cb6258d4c544155 + 3.43% 3.43% stress stress [.] 0x0000000000002eff + 3.20% 0.00% stress [kernel.kallsyms] [k] page_fault + 3.20% 0.00% stress [kernel.kallsyms] [k] do_page_fault + 3.15% 0.76% stress [kernel.kallsyms] [k] __do_page_fault
作者回复: 嗯嗯 很好的问题。简单的说,swapper跟我们要分析的对象无关。这也是为什么我们不上来就用perf,而是先用其他方法缩小范围。我还会在答疑篇里解释swapper的作用
2018-12-16716 - bruceding对于内核函数的调试,4.0 的内核可以使用 eBPF 工具,2.6 或者 4.0 以下的工具,使用 systemtap。perf 是基于采样的原理。本文的例子 execsnoop 可以替换成 https://sourceware.org/systemtap/SystemTap_Beginners_Guide/threadtimessect.html。systemtap 中文资料比较少,本人也翻译了相关文档,参考:http://systemtap.bruceding.com/。
作者回复: 👍,谢谢分享经验。使用低版本内核的用户可以试试 链接里面的 thread-times.stp。
2019-02-126 - 每一段路都是一种领悟今天一个程序负载飙到140,最高点240,我们的服务器没有挂掉,真的是牛逼,另外使用这几天的方法,基本确认了程序的问题,质问开发后,他不好意思的告诉我,io高是因为自己程序偷了懒,好在这次找到证据了,作为以后的分析案例
作者回复: 😊
2018-12-2425 - Griffin实际生产环境中的进程更多,stress藏在ps中根本不容易发现,pstree的结果也非常大。老师有空讲讲如何找到这些异常进程的方法和灵感。
作者回复: 嗯嗯,这是一个模块,侧重于CPU的分析,后面还会讲磁盘、网络等等
2018-12-095 - walkerexecsnoop这个工具在centos里找不到,有类似的代替品吗
作者回复: 点击链接到github上。 完全一样的工具应该没有,但可以基于内核追踪技术(比如BPF)来自己写一个。
2018-12-0334 - 小贝_No_7最后的perf -g有疑问。这里并没有展示出明显的stress占比较高的情况。相反是swapper较多, stress的占比其实在10%一下。请问这个怎么解释? 我看到底下也有其他朋友有类似的疑问但是没得到很好的解析。谢谢啦。
作者回复: 请参考 14 | 答疑(二):如何用perf工具分析Java程序
2019-05-033 - 夜空中最亮的星execsnoop 这个工具没找到
作者回复: 之前的链接有错误,已经修复了,可以点击链接跳过去
2018-12-033