点击上方“蓝字”可以关注我们哦

点击查看源网页

|转载自：嵌入式Linux中文站

|原文链接：http://mp.weixin.qq.com/s/D5amm2_AevD2smWuWcDpBA

昨天搞定了一个十万火急的issue，客户抱怨产品升级后系统会变慢和CPU使用率相当高，思解决问题的过程，觉得这个分析过程具有可复用性，值得总结一下。

1.用top命令查看哪个进程占用CPU高

gateway网关进程14094占用CPU高达891%，这个数值是进程内各个线程占用CPU的累加值。

2.用top -H -p pid命令查看进程内各个线程占用的CPU百分比

#top -H -p 14094

top中可以看到有107个线程，但是下面9个线程占用CPU很高，下面以线程14086为主，分析其为何high CPU

3.使用gstack命令查看进程中各线程的函数调用栈

#gstack 14094 > gstack.log

在gstack.log中查找线程ID14086，由于函数栈会暴露函数细节，因此只显示了两个函数桢，线程ID14086对应线程号是37

Thread 37 (Thread 0x4696ab90 (LWP 14086)):
#0 0x40000410 in __kernel_vsyscall ()
#1 0x40241f33 in poll () from /lib/i686/nosegneg/libc.so.6

4.使用gcore命令转存进程映像及内存上下文

#gcore 14094
该命令生成core文件core.14094

5。用strace命令查看系统调用和花费的时间

#strace -T -r -c -p 14094

-c参数显示统计信息，去掉此参数可以查看每个系统调用话费的时间及返回值。

6.用gdb调试core文件，并线程切换到37号线程

gcore和实际的core dump时产生的core文件几乎一样，只是不能用gdb进行某些动态调试

(gdb) gdb gateway core.14094
(gdb) thread 37
[Switching to thread 37 (Thread 0x4696ab90 (LWP 14086))]#0  0x40000410 in __kernel_vsyscall ()
(gdb) where
#0  0x40000410 in __kernel_vsyscall ()
#1  0x40241f33 in poll () from /lib/i686/nosegneg/libc.so.6

可以根据详细的函数栈进行gdb调试，打印一些变量值，并结合源代码分析为何会poll调用占用很高的CPU。

因为代码涉及到公司产权，顾不在此做详细分析，需要明白的是分析的流程和使用的命令。

流程为：进程ID->线程ID->线程函数调用栈->函数耗时和调用统计->源代码分析