Linux下 CUP 占有率高?给你这样的调试方法
点击蓝色字关注 "CU技术社区" 一起玩耍哦~
转载自 | 嵌入式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->线程函数调用栈->函数耗时和调用统计->源代码分析
2017 就这样手把手把你交给 2018:来年请对全体IT人好一点!
Python将被纳入高考,小学生都在学Python,你慌了吗?49 30601 49 15174 0 0 979 0 0:00:31 0:00:15 0:00:16 3545ng>
Linux 企业运维人员最常用 150 个命令汇总! 收藏了!
Python 这么热,运维要不要追赶 Python 的热潮?
砸 4 亿上 Win10 ,慕尼黑正式叫停 Linux 开源计划
用开源软件写的57行代码,PK掉8600 54 30601 54 16534 0 0 1004 0 0:00:30 0:00:16 0:00:14 3500的商业项目!
《2017年度中国混合云优秀案例集锦》
现已开放下载了!
微信后台回复:混合云 即可收到下载链接