老李案例分享:MAT分析应用程序服务出现内存溢出过程

老李案例分享:MAT分析应用程序服务出现内存溢出过程

 

   poptest是国内唯一一家培养测试开发工程师的培训机构,以学员能胜任自动化测试,性能测试,测试工具开发等工作为目标。在poptest的loadrunner的培训中,为了提高学员性能优化的经验,加入了很多服务器方面的优化知识,为性能调优的能力打下基础,通过大量的实战案例的讲解提高学员的实战经验,尽快上手性能测试。(大家对课程感兴趣,请加qq:564202718)

说明:系统在并发情况下后台出现java.lang.OutOfMemoryError:GC overhead limit exceeded错误,利用工具loadrunner 、AWR报告、jstack、MAT等进行性能分析
1、用LoadRunner做50用户并发,先进行2分钟的预热测试,为了系统能用到缓存的地方都先进行缓存,然后进行5分钟的施压测试。(通过loadrunner的controller中设置,大家可以看看loadrunner手册)
2、大约运行7分钟左右,后台出现“java.lang.OutOfMemoryError”错误信息;

错误信息如下:

3、出现OutOfMemoryError错误信息,一般出现该错误信息是堆内存的溢出,所以我们需要考虑捕捉一下堆内存的信息,捕捉堆内存的信息有2种方式:

3.1 通过在应用中间件(weblogic、tomcat 等)上加入相应的JVM参数,具体参数如下(加入参数后,系统在出现OutOfMemoryError错误的时候便会自动生成类似java_pid9388.hprof的这样一个文件):

-Xloggc:D:heapdumpmanaged1_gc.log

-XX:+HeapDumpOnOutOfMemoryError

-XX:HeapDumpPath=D:heapdump

3.2 使用JDK自带的JMAP工具,具体使用方法如下:
  第一步:先用jps.exe命令找到相应的java进程ID,一般找Server PID的;
  第二步:jmap.exe-dump:format=b,file=d:dumpjava_pid(第一步查询到的PID号).hprof PID(该地方一定要空格后跟着相应的PID号)如果只dump heap中的存活对象,则加上选项-live,如下:jmap.exe -dump:live,format=b,file=/path/heap_pid. hprof 进程ID(PID)

4.使用MAT工具来分析生成的hprof文件内容
4.1打开需要分析的hprof文件:
4.2 在Overview(概述)界面利用饼图的摘要信息来分析哪些对象比较占内存

4.3分析Action部分内容:

4.3.1点击“Leak Suspects”后的结果如下:

4.3.2 在怀疑问题的第点Details

4.3.3查看有问题的的类所引用的所有对象。此时使用鼠标左键点击,然后弹出菜单中进行如下选择:List Objects->with outgoing references

(说明:

图中的Shallow Heap(浅堆):指对象自身占用内存的大小,不包括它引用的对象。

图中的 Retained Heap(深堆):指当前对象大小+当前对象可直接或间接引用到对象的大小总和

此时可以点击鼠标左键,将sql语句的内容进行拷贝.

此时就找到了问题。

另述:

其实上述第4步找问题的步骤可以简化为在Overview的饼图中通过选择Path to GC Roots 来发现JAVA的内存泄露问题

Pathto GC Roots:被JVM持有的对象,如当前运行的线程对象,被systemclass loader加载的对象被称为GC Roots, 从一个对象到GC Roots的引用链被称为Pathto GC Roots, 通过分析Pathto GC Roots可以找出JAVA的内存泄露问题,当程序不在访问该对象时仍存在到该对象的引用路径。)

原文地址:https://www.cnblogs.com/poptest/p/4897029.html