MAT发现导致OOM的具体功能表单的过程

背景

愚人节这一天公司项目出现了 大量FullGC的情况.
群里发出来之后这边进行了一些简单的问题查找.

堆区设置的事 30G 然后 dump文件是 35G左右.
下载和解压缩耗时 15min
使用40G堆区 全闪的Window虚拟机进行解析
耗时 30分钟.

最近自己眼神不是特别好使, 找东西总是很费劲
所以想总结一下, 方便后续进行类似的工作. 

文件情况说明

堆区设置的事30G大小

dump文件为 33.8G
mat解析后所有文件大小为 79GB

说明 堆外内存大约有4GB以上. 
mat解析会昌盛大量的 index文件. 是堆区大小的1.5 倍. 

mat解析的整体情况

堆区设置是 30G 内存占用是 26.5G左右. 
一般情况下抓取dump会进行一次fullGC. 
至少有一部分 FROM TO区域是空的
并且部分年轻代 也会倍清理, 所以一般不会到达 30G的巅峰数值.

点击齿轮查看线程信息

与一般的tracelog不同 mat分析会对每一个进程的 关联内存进行对应

所以这个使用内存排序很快就可以知道是哪个线程的问题了. 

左击最大内存区域 list outgoing object

注意在overview区域是需要 左键单击的
建议选择 outgoing的 对象
这是就可以展示对象全貌了. 

需要注意, 不要无限制的去点击最大的内存, 一般只需要在当前层次查看就可以了
无限制的下一级是没有意义的. 

注意事项

String 对象可能是比较核心的部分, 如果是 % 分割 
可以放到chrome 里面会帮忙转换成中文. 

如果是 0x开头的 可以 复制为 value 
也会转换为中文. 

Oracle相关的会将 连接串给出来. 

还有就是 业务代码相关的可以评判是哪个关键应用的功能异常.

查找表单ID

根据这边 丁杨老师的讲解.  可以通过查找 coyote 郊狼组件查看到具体的 url

需要说明:
apache tomcat 是应用服务器 coyote 郊狼是一个http 的工具链
里面会有具体的url 可以找到对应的表单
所以在list outgoing object 里面根据object name进行排序
查找 <org.apache.coyote.Request>  类似的对象
可以在 <header> 对象进行 查找. 

一般会有多个对象 可以根据序号进行查找, 会在7-12个序号之间 找到对应的url

注意选择的 VALUEB的对象进行