linux进程高cpu问题分析


linux进程高cpu问题分析
1.用top命令查看哪个进程占用CPU高
gateway网关进程14094占用CPU高达891%,这个数值是进程内各个线程占用CPU的累加值。
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14094 root 15 0 315m 10m 7308 S 891% 2.2 1:49.01 gateway
20642 root 17 0 17784 4148 2220 S 0.5 0.8 2:39.96 microdasys
1679 root 18 0 10984 1856 1556 R 0.3 0.4 0:22.21 sshd
22563 root 18 0 2424 1060 800 R 0.3 0.2 0:00.03 top
1 root 18 0 2156 492 460 S 0.0 0.1 0:01.59 init
2.用top -H -p pid命令查看进程内各个线程占用的CPU百分比
#top -H -p 14094
top中可以看到有107个线程,但是下面9个线程占用CPU很高,下面以线程14086为主,分析其为何high CPU
PID USER PR NI VIRT RES SHR S %CPU MEM TIME+ COMMAND
14086 root 25 0 922m 914m 538m R 101 10.0 21:35.46 gateway
14087 root 25 0 922m 914m 538m R 101 10.0 10:50.22 gateway
14081 root 25 0 922m 914m 538m S 99 10.0 8:57.36 gateway
14082 root 25 0 922m 914m 538m R 99 10.0 11:51.92 gateway
14089 root 25 0 922m 914m 538m R 99 10.0 21:21.77 gateway
14092 root 25 0 922m 914m 538m R 99 10.0 19:55.47 gateway
14094 root 25 0 922m 914m 538m R 99 10.0 21:02.21 gateway
14083 root 25 0 922m 914m 538m R 97 10.0 21:32.39 gateway
14088 root 25 0 922m 914m 538m R 97 10.0 11:23.12 gateway
3.使用gstack命令查看进程中各线程的函数调用栈
#gstack 14094 > gstack.log
在gstack.log中查找线程ID14086,由于函数栈会暴露函数细节,因此只显示了两个函数桢,线程ID14086对应线程号是37
Thread 37 (Thread 0x4696ab90 (L WP 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
通用的完整用法:
strace -o output.txt -T -tt -e trace=all -p $pid
上面的含义是 跟踪28979进程的所有系统调用(-e trace=all),并统计系统调用的花费时间,以及开始时间(并以可视化的时分秒格式显示),最后将记录结果存在output.txt文件里面。
-c参数显示统计信息,去掉此参数可以查看每个系统调用话费的时间及返回值。
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------------------
99.99 22.683879 3385 6702 poll
0.00 0.001132 0 6702 gettimeofday
0.00 0.000127 1 208 208 accept
0.00 0.000022 22 1 read
0.00 0.000000 0 1 write
0.00 0.000000 0 1 close
0.00 0.000000 0 14 time
0.00 0.000000 0 2 stat64
0.00 0.000000 0 4 clock_gettime
0.00 0.000000 0 7 send
0.00 0.000000 0 10 10 recvfrom
------ ----------- ----------- --------- --------- ------------------------------
100.00 22.685160 13652 218 total
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。






在工作当中,肯定会遇到由代码所导致的高CPU耗用以及内存溢出的情况。这种情况发生时,我们怎么去找出原因并解决。

一般解决方法是通过top命令找出消耗资源高的线程id,利用strace命令查看该线程所有系统调用

1. 通过top命令找到可疑进程PID

top - 09:37:18 up 70 days, 16:29,  2 users,  load average: 1.13, 1.04, 0.97
Tasks: 105 total,   1 running, 104 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.0%us,  4.9%sy,  0.0%ni, 93.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.5%st
Mem:   2067816k total,  1756680k used,   311136k free,   236340k buffers
Swap:   524284k total,   255508k used,   268776k free,   277040k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
24138 apache    20   0 1273m 384m 3668 S 103.3 19.0   1232:39 java
 3359 root      39  19  2704   36    0 S  0.3  0.0   4:39.34 gam_server
 6696 root      20   0 34148 1604  244 S  0.3  0.1   5:06.63 httpd
19254 root      20   0  785m 221m 3176 S  0.3 11.0   9:04.36 java
    1 root      20   0  2224   28    0 S  0.0  0.0   1:22.46 init
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd
    3 root      20   0     0    0    0 S  0.0  0.0   0:33.42 ksoftirqd/0
    5 root      20   0     0    0    0 S  0.0  0.0   0:00.03 kworker/u:0

从上面命令中可以看出java进程CPU利用率一直保持100%,稳居不下,找到PID 24138

2. 找出消耗资源最高的线程

top -H -p 24138可以不用第一步,直接执行命令top -H,就可以查看到消耗资源最高的线程

top - 09:49:49 up 70 days, 16:41,  2 users,  load average: 1.01, 1.04, 1.00
Tasks:  72 total,   1 running,  71 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.6%us,  1.3%sy,  0.0%ni, 97.7%id,  0.1%wa,  0.0%hi,  0.0%si,  0.2%st
Mem:   2067816k total,  1760840k used,   306976k free,   236744k buffers
Swap:   524284k total,   253344k used,   270940k free,   279092k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
24167 apache    20   0 1273m 384m 3688 R 99.1 19.0   1169:43 java
24152 apache    20   0 1273m 384m 3688 S  2.0 19.0   0:28.58 java
24188 apache    20   0 1273m 384m 3688 S  2.0 19.0   4:56.69 java
24138 apache    20   0 1273m 384m 3688 S  0.0 19.0   0:00.00 java
3. 查看这个线程所有系统调用
strace -p 24167
通过这3步基本可以找出什么原因导致java进程占用那么高CPU资源

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
当我们在使用Linux系统中遇到CPU占用过的情况,通常会使用top命令来查看当前正在运行的进程和它们的CPU占用情况。然而,有时候我们可能会遇到一种情况,即CPU占用很,但在top命令的输出中却无法看到相应的进程。 造成这种情况的原因可能有以下几种: 1. 进程已经结束:有时候,一个进程CPU占用峰期间已经结束,但在我们运行top命令时,可能只是恰好错过了它的存在。这时候,我们可以尝试使用其他的进程监控工具,如htop,来更详细地查看系统进程的使用情况。 2. 优先级较低的进程Linux系统中,进程的优先级是由调度器来决定的。如果一个进程的优先级较低,可能会被其他优先级较进程抢占CPU资源,导致其在top命令中不容易被观察到。在这种情况下,我们可以尝试使用nice命令来提进程的优先级,使其能够更好地被top命令监控到。 3. 虚拟化环境中的情况:在使用虚拟化技术的环境中,有时候CPU占用过进程可能是位于虚拟机中而不是宿主机系统中。top命令只能观察到宿主机系统中的进程情况,而无法直接观察到虚拟机内部的情况。这时候,我们需要在虚拟机内部进行进一步的进程监控,例如使用虚拟机内部的类似top命令的工具。 综上所述,当我们在Linux系统中遇到CPU占用却无法在top命令中看到相关进程时,我们可以尝试使用其他的进程监控工具,检查进程是否已经结束、调整进程的优先级,或在虚拟化环境中进行更详细的进程监控。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值