IBM jca 工具的学习与整理

IBM jca 工具的学习与整理

---

背景

发现自己最早看到IBM这个工具的时间是 2022年9月份.
但是一直没有进行过仔细的学习与论证. 

本周出现了一个问题. 虽然通过gclog明显看出来是一个oom
然后内存对象里面排第一的是 hashnode 相关内容
猜测出可能是excel导入/导出相关的内容

但是自己并没有快速的从jstack 里面找出来具体的线程
还是通过 mat 分析dump文件才找到的具体功能的操作.

感觉自己对jstack的分析一直比较怵头
感觉他的文档结果不好看, 自己的确也有点密集恐惧症,
对这种文档的分析总是不得要领.
所以想经过这次事件,还是多学习一下jstack的分析
寄希望于dump 文件太大了. 速度太慢.
有时候黄花菜都凉了.

---

工具下载

https://www.ibm.com/support/pages/ibm-thread-and-monitor-dump-analyzer-java-tmda
文件其实比较小.
最新版本是 4.6.16.
文件名是:
jca4616.jar

---

快捷方式

可以将文件放到一个目录下面, 然后修改文件名
jca.jar
添加一个 bat 脚本

@echo off
java -jar jca.jar

双击就可以使用这个工具了.

---

抓取信息

pid=`ps -ef |grep java |grep $mainclassname|grep -v grep |awk '{print $2}'`
now=`date +%Y%m%d%H%M`
jcmd $pid VM.uptime >>trace_$now.log \;
jcmd $pid VM.flags >>trace_$now.log \;
jcmd $pid Thread.print >>trace_$now.log \;
jcmd $pid GC.class_histogram -all >>trace_$now.log \;
jcmd $pid GC.heap_info >>trace_$now.log \;

---

分析与查看

IBM其实是J9 jvm的开发商
他的mat和jca工具都非常不错.
mat可以分析dump文件
jca可以快速的分析 jstack等信息. 也可以分析 dump 文件. 

jca最重要的几项工作主要如下

---

总要功能界面

---

thread status analysis

• 能够对 thread的状态进行分组. 界面化比较好看.
  
  

---

Methad analysis

• 可以对主要的方法进行pie图的区分
  
  

---

Thread Detail

• 查看线程的具体信息, 可以排序. 比看txt优雅很多
• 注意线程名前面有一个console标签的说明有等待
  
  

---

Monitor Detail

• 可以查看拥有锁以及被锁的线程明细信息

---

异常日志分析

其实 内存的histogram 信息能够看到一个很明显的增多的情况:
 num     #instances         #bytes  class name
----------------------------------------------
   1:     277303736     8873719552  java.util.HashMap$Node
   2:       2752253     1928937296  [Ljava.util.HashMap$Node;

发现极度怀疑是 hashmap 的一些处理导致问题.
然后分析jstack的堆栈, 可以看到一个明显的进程信息:

"http-nio-5200-exec-134" #131057 daemon prio=5 os_prio=0 tid=0x00007f5a343e0000 nid=0x12fac7 runnable [0x00007f58257d2000]
   java.lang.Thread.State: RUNNABLE
	at java.util.HashMap.newNode(HashMap.java:1750)
	at java.util.HashMap.putVal(HashMap.java:631)
	at java.util.HashMap.put(HashMap.java:612)

所以极度怀疑是这个线程出现的问题
然后可以通过堆栈的进一步分析, 去查看自己产品的堆栈信息来判断是哪个功能有问题. 

然后有条件的分析一下dump文件, 说补丁能够看到具体的功能. 有概率看到具体的文件.

---

excel的处理

其实处理excel 跟处理证券类似, 都有"胖手指" 的现象.
本次事故的核心原因就是 excel 有一个快速的复制功能. 

在复制某一个单元格之后, 单机任意一栏的标题栏. ctrl + v 就可以将整个excel的当前栏替换掉

因为 2007版本的excel 已经完善了 excel的最大列数和行数
2003版最大行数是65536行，最大列数是256列。
Excel2007及以后的版本最大行数是1048576行，最大列数是16384列

如果1M行数全部有数据进入 内存里面就会消耗非常多的内存信息.
所以还是应该提前使用poi的方式来检查行数和列数.  避免出现此类问题.

---

使用的内存量计算

通过mat 分析dump文件可以看到
空行excel 大概占用 13KB的内存.
如果1M的excel 文件大概需要 13G的内存.
如果老年代大于20GB. 留下 7G左右给常规使用的环境
理论上可以支撑住这样的有异常的文件 只是大家都可能会卡一些. 

所以有时候 可以通过技术手段解决问题, 有时候也可以通过钱来解决问题.

---