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
