leak suspect_MemoryAnalyzer.exe_celebrity leak

1031问题分析之CPU 100%

10-31日出现过一次问题，服务器上执行top命令按键1观察始终有一个cpu占用总100%，怀疑可能是因后台服务请求过多CPU繁忙导致访问慢。

将后台服务切到备机，通过堆栈分析具体那段代码引起的CPU占用100%问题。

问题定位过程：

1）jps -m 非常方便直接定位所有的Java进程pid

[root@cdn ldw]# jps -m | grep 28081

6687 WatchdogManager start -conf /ldw/conf/resin/resin-mms-webapp-28081.xml --log-directory /ldw/apps/resin/log

6734 Resin --root-directory /ldw/apps/resin/ -conf /ldw/conf/resin/resin-mms-webapp-28081.xml -server default -socketwait 15304 start --log-directory /ldw/apps/resin/log

找到占用CPU利用率最高的pid，一般CPU利用率达到90%以上，将pid转换为16进制，方法有很多种，我使用linux自带python命令：hex(pid)，很方便。

at com.xxx.inteces.util.NoticeMonitorSysHelper$ThreadStatue$1.run(NoticeMonitorSysHelper.java:167)

at java.lang.Thread.run(Thread.java:722)

5）fix代码，重新部署上线

观察cpu迅速降到正常值，swap值也降下来了，第二天观察cpu、swap并没有明显的增加。leak suspect

6）在备机切换到线上机器前，通过jmap打印出JVM堆内存信息

jmap -dump:live,format=b,file=heap1031.bin <pid>

1212问题分析之内存泄漏

12-11日晚VRS系统又一次服务Down掉，但是当时收到反馈后并没有及时切到备机，未能及时保留问题现场，紧急重启后暂时恢复服务，此时距离上一次上线间隔为9D。

通过Zabbix监控来看swap内存这些天每天都在升高，最大值占用了接近4G，可服务器总内存不过才6G，初步定位肯定是Java应用内存泄漏导致。

第二天一块讨论这块问题如何排查，内存泄漏一般通过jstack输出的栈很难定位到问题，只能对JVM堆内存信息做分析。

这次问题也联想到上次故障处理后，实际并没有找到问题根本原因，想到了1031日存留过JVM堆信息heap1031.bin，然后下载到本地通过MAT(Eclipse插件)进行内存分析。也可以通过其他工具如jhat，但不如MAT直观。

问题定位过程：

进入Eclipse：Memory ysis

选择File—》Open Head Dump…打开heap1031.bin

会弹出一个对话框，选择Leak Suspects Report 【自动检测存疑的泄漏点，会报告出那些存活的对象以及这些对象没有被gc的原因】

MAT会自动分析出内存大致情况，直方图显示内存占用以及Problem Suspect

通过以上会看到1635个JPEGImageReader实例没有被释放，可能这个是导致内存泄漏的根源，也说明跟系统裁图功能有关，缩小了问题定位范围。

没有释放资源怀疑可能是IO流没有正常关闭导致，因JVM堆栈转存只看到底层代码，具体还要进一步分析程序源代码。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-48515-1.html