Java程序导致服务器CPU占用率过高的问题
Java程序导致服务器CPU占用率过高的问题
1、故障现象
客服同事反馈平台系统运行缓慢,网页卡顿严重,多次重启系统后问题依然存在,使用top命令查看服务器情况,发现CPU占用率过高。
2、CPU占用过高问题定位
2.1、定位问题进程
使用top命令查看资源占用情况,发现pid为14063的进程占用了大量的CPU资源,CPU占用率高达776.1%,内存占用率也达到了29.8%
[ylp@ylp-web-01 ~]$ top
top - 14:51:10 up 233 days, 11:40, 7 users, load average: 6.85, 5.62, 3.97
Tasks: 192 total, 2 running, 190 sleeping, 0 stopped, 0 zombie
%Cpu(s): 97.3 us, 0.3 sy, 0.0 ni, 2.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 16268652 total, 5114392 free, 6907028 used, 4247232 buff/cache
KiB Swap: 4063228 total, 3989708 free, 73520 used. 8751512 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14063 ylp 20 0 9260488 4.627g 11976 S 776.1 29.8 117:41.66 java
2.2、定位问题线程
使用ps -mp pid -o THREAD,tid,time命令查看该进程的线程情况,发现该进程的多个线程占用率很高
[ylp@ylp-web-01 ~]$ ps -mp 14063 -o THREAD,tid,time
USER %CPU PRI SCNT WCHAN USER SYSTEM TID TIME
ylp 361 - - - - - - 02:05:58
ylp 0.0 19 - futex_ - - 14063 00:00:00
ylp 0.0 19 - poll_s - - 14064 00:00:00
ylp 44.5 19 - - - - 14065 00:15:30
ylp 44.5 19 - - - - 14066 00:15:30
ylp 44.4 19 - - - - 14067 00:15:29
ylp 44.5 19 - - - - 14068 00:15:30
ylp 44.5 19 - - - - 14069 00:15:30
ylp 44.5 19 - - - - 14070 00:15:30
ylp 44.5 19 - - - - 14071 00:15:30
ylp 44.6 19 - - - - 14072 00:15:32
ylp 2.2 19 - futex_ - - 14073 00:00:46
ylp 0.0 19 - futex_ - - 14074 00:00:00
ylp 0.0 19 - futex_ - - 14075 00:00:00
ylp 0.0 19 - futex_ - - 14076 00:00:00
ylp 0.7 19 - futex_ - - 14077 00:00:15
从输出信息可以看出,14065~14072之间的线程CPU占用率都很高
2.3、查看问题线程堆栈
挑选TID为14065的线程,查看该线程的堆栈情况,先将线程id转为16进制,使用printf "%x\n" tid命令进行转换
[ylp@ylp-web-01 ~]$ printf "%x\n" 14065
36f1
再使用jstack命令打印线程堆栈信息,命令格式:jstack pid |grep tid -A 30
[ylp@ylp-web-01 ~]$ jstack 14063 |grep 36f1 -A 30
"GC task thread#0 (ParallelGC)" prio=10 tid=0x00007fa35001e800 nid=0x36f1 runnable
"GC task thread#1 (ParallelGC)" prio=10 tid=0x00007fa350020800 nid=0x36f2 runnable
"GC task thread#2 (ParallelGC)" prio=10 tid=0x00007fa350022800 nid=0x36f3 runnable
"GC task thread#3 (ParallelGC)" prio=10 tid=0x00007fa350024000 nid=0x36f4 runnable
"GC task thread#4 (ParallelGC)" prio=10 tid=0x00007fa350026000 nid=0x36f5 runnable
"GC task thread#5 (ParallelGC)" prio=10 tid=0x00007fa350028000 nid=0x36f6 runnable
"GC task thread#6 (ParallelGC)" prio=10 tid=0x00007fa350029800 nid=0x36f7 runnable
"GC task thread#7 (ParallelGC)" prio=10 tid=0x00007fa35002b800 nid=0x36f8 runnable
"VM Periodic Task Thread" prio=10 tid=0x00007fa3500a8800 nid=0x3700 waiting on condition
JNI global references: 392
从输出信息可以看出,此线程是JVM的gc线程。此时可以基本确定是内存不足或内存泄露导致gc线程持续运行,导致CPU占用过高。
所以接下来我们要找的内存方面的问题
3、内存问题定位
3.1、使用jstat -gcutil命令查看进程的内存情况
[ylp@ylp-web-01 ~]$ jstat -gcutil 14063 2000 10
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 0.00 100.00 99.99 26.31 42 21.917 218 1484.830 1506.747
0.00 0.00 100.00 99.99 26.31 42 21.917 218 1484.830 1506.747
0.00 0.00 100.00 99.99 26.31 42 21.917 219 1496.567 1518.484
0.00 0.00 100.00 99.99 26.31 42 21.917 219 1496.567 1518.484
0.00 0.00 100.00 99.99 26.31 42 21.917 219 1496.567 1518.484
0.00 0.00 100.00 99.99 26.31 42 21.917 219 1496.567 1518.484
0.00 0.00 100.00 99.99 26.31 42 21.917 219 1496.567 1518.484
0.00 0.00 100.00 99.99 26.31 42 21.917 220 1505.439 1527.355
0.00 0.00 100.00 99.99 26.31 42 21.917 220 1505.439 1527.355
0.00 0.00 100.00 99.99 26.31 42 21.917 220 1505.439 1527.355
从输出信息可以看出,Eden区内存占用100%,Old区内存占用99.99%,Full GC的次数高达220次,并且频繁Full GC,Full GC的持续时间也特别长,平均每次Full GC耗时6.8秒(1505.439/220)。根据这些信息,基本可以确定是程序代码上出现了问题,可能存在不合理创建对象的地方
3.2、分析堆栈
使用jstack命令查看进程的堆栈情况
[ylp@ylp-web-01 ~]$ jstack 14063 jstack.out
把jstack.out文件从服务器拿到本地后,用编辑器查找带有项目目录并且线程状态是RUNABLE的相关信息,从图中可以看出ActivityUtil.java类的447行正在使用HashMap.put()方法
Paste_Image.png
3.3、代码定位
打开项目工程,找到ActivityUtil类的477行,代码如下:
Paste_Image.png
找到相关同事了解后,这段代码会从数据库中获取配置,并根据数据库中remain的值进行循环,在循环中会一直对HashMap进行put操作。
查询数据库中的配置,发现remain的数量巨大
Paste_Image.png
至此,问题定位完毕。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
[python skill]基于python的bootstrap analysis方法
上回书说到(惊堂木!)Dr. Semmelweis and the discovery of handwashing案例中的第8步中使用了bootstrap分析方法(Bootstrap analysis of Semmelweis handwashing data),其实小弟内心写起来是有一丢丢心虚的,因为本身不是相关专业出身没有系统学习过概率学的方法,加之互联网时代大家皮糙肉厚,其实没太多时间仔细研究某一种具体的方式方法(可能只有我一个人这样)。碰巧,今天datacamp里面学习的一章节内容就是根据bootstrap analysis方法展开的。所以趁着工作室打烊前的小空隙,总结一下今天下午的学习成果。 所谓bootstrap analysis: 在统计学中,自助法(Bootstrap Method,Bootstrapping或自助抽样法)是一种从给定训练集中有放回的均匀抽样,也就是说,每当选中一个样本,它等可能地被再次选中并被再次添加到训练集中。自助法由Bradley Efron于1979年在《Annals of Statistics》上发表。当样本来自总体,能以正态分布来描述,其...
- 下一篇
java之 ------------[LeetCode] House Robber 打家劫舍
刚开始做这一道题感觉卧槽,这不简单吗,直接去把数组下标和2取余的数相加再把剩下的数相加,比较这两个和谁大就输出谁,不就行了,但是啊,我操,事实证明,我还是太天真了,我操出现[2,1,1,2]这种情况,我当时还怀疑为什么那么简单后来一想,我操,这不是动态规划吗,于是乎,恶补一下怎么实现动态规划的,说白了,动态规划就是把大的数据拆成小的数据,如我想计算f(10),我就要计算出f(9)+1,然后我想计算出f(9)=f(8)+1,递推的方式直到f(1)=f(0)+1,就结束了。就是上面的结果依赖与下边的结果。 /* 注意这里的返回值,你一定在疑惑为什么返回值,返回的是arry.length-1,那是因为我刚开始计算的时候 * 就涉及到前三个数字,如果返回arry.length,那么会报越界异常。 * 其实啊,说白了,就是【表情】那个对一个数组的递推,只不过借助一个空的数组来实现 * 前期给【表情】【表情】这个空的数组赋初值,这里是两个,借助的这个数组就前两个是有值的,其它没值 * */ public int leastPath(int[] arry) { int length = arry.l...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS7安装Docker,走上虚拟化容器引擎之路
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8编译安装MySQL8.0.19
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS关闭SELinux安全模块