IBM_mat工具的学习与整理

背景

客户现场出现了大并发时访问异常的情况。
一开始以为是配置较低撑不住大并发的场景导致的。
然后将异常时期的dump导出来到公司后进行了一下分析
发现并不完全如此， 自己对硬件能够支撑的并发量其实判断是有错误的。 
mat工具自己账务的也不是很好。 
丁杨老师发下你可以通过dump 找到具体的执行SQL进行判断。
我一开始一直没找到具体的点， 
然后发现自己对mat的使用的确太低级了，所以想总结一下备忘。 

感谢工作中给与灵感的各位同事

情况说明-dump文件的形成

第一种： 
dump 文件可以使用 oomerror的方式自动生成。 
可以再启动脚本里面进行配置：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./dump

第二种：
如果是kill -4 或者是堆栈内存错误导致被操作系统kill可以修改一下内容
ulimit -c umlimited 
然后修改dump文件的形成：
可以通过修改 /etc/sysctl.conf 进行修改默认文件名和路径
kernel.core_pattern = /var/core_%e_%t_%p
如果jmap命令失效可以通过如下命令生成core文件
time gcore  $pid -o core
可以通过如下命令进行转换：
jstack x86_64-linux/bin/java core.5989
jmap -dump:live,format=b,file=core.5989.hprof  x86_64-linux/bin/java core.5989
可以生成dump文件。 

mat的使用建议

1.使用大内存高主频的机器进行分析，速度会快很多。
2.使用SSD存储的设置进行分析，因为mat分析过程中会产生很多index文件
  快速硬盘能够加快分析速度。
3. 修改配置，建议堆区至少大于产生dump的java进程内存配置
范例： MemoryAnalyzer.ini 
-startup
plugins/org.eclipse.equinox.launcher_1.6.400.v20210924-0641.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.2.400.v20211117-0650
-vmargs
-Xmx40960M
-Xms40960M

磨刀不误砍柴工
快速的机器能够极大的提高问题定位的速度。

mat查找异常问题SQL-excel文件

这里参照丁杨老师的方案进行处理
其他比较简单的处理不再赘述。 

1. 打开mat，打开dump文件分析。 如果dump文件在30G左右
   如果采取SSD的高速存储大内存的windows机器，预计可以再半小时之内解析完。
2. 解析完成之后， 没太有必要进行直接的memory leak 分析
   建议直接点击 工具栏的 齿轮状按钮。 打开 thread_overview 
3. 按照内存进行排序，将内存使用量较大的线程放到前面。
   然后右键点击对应的线程，一般为 tomcat的 TaskThread类型。
   点击 List objects 选择 outgoing references 
4. 在打开的 list_objects 里面进行查找 
   如果是 不分页SQL导致的话能够找到对应的SQL文件。
   如果是 导入大型excel导致内存出问题的话可以找到对应的excel文件名。

需要注意 查找过程中需要仔细认真
可能有比较多的 java local 对象， 需要仔细查看分析。
不然会出现误判的问题。 

感谢丁杨老师提供的方案。 这里仅是进行一下记录， 备忘并且便于后续问题的排查。