openj9内存分析

    在paas环境上使用kill -3 pid命令会生成两个文件，dump和javacore,其中dump指文件名如 dump-dump-user-2018-07-16-08-20-04.0001.phd 的文件，为openj9堆转储文件。javacore指名称如javacore-dump-2018-07-16-08-20-04.0002.txt的openj9线程转储文件。

    当使用mat工具打开*.phd和使用jca4.jar打开.txt文件时都有界面显示内存占用，有同学疑问这里两个内存和gclog，docker stats的内存关系。

    从javacore看到的堆内存如下:、

    从mat看到的内存信息如下

:

 

可以看出虽然dump文件和javacore文件内存虽然有差距，但是保持在一个数量级。其中的差异跟shallow ,deep ,retained对象概念有关,图中展示的是retained size，而非deep size，retained size是指回收改对象能释放的内存大小，该内存不包括与其它对象共用的内存，故小于deep size。

 

另外，很多同学会疑虑javacore和dump文件的堆内存为什么跟gclog日志里<mem-info>不一致。确认这个问题之前首先要清楚gc日志打印内容的含义，这部分可参考openj9文档

 

。需要说明的是使用Kill -3 pid生成的javacore和dump文件是经过了full gc 的(仅对堆中存活的对象有效——会在下一次Full GC 周期内被回收的对象不会包含在工具的输出中，此特性适用于绝大部分堆分析工具)，在gclog里面对应<gc-start type="global">的标签内容。而大部分同学看的gc内存是<gc-start id="348" type="scavenge">的

 

docker stats 命令查看到的内存规则参考paas团队说明文档；该命令是以docker为单位查看内存，包括jvm和非jvm部分，所以个人理解原则上要稍大于jvm的实际占用内存，更要大于jvm堆内存。

在paas平台的监控页面看到内存在某个点增高以后一直没有下降，或者长时间内存曲线呈增长型，没有观察到GC的渐变过程。这是因为paas平台页面监控的是Docker的内存，JVM堆内存不够时向操作系统申请的内存在JVM GC后没有归还给操作系统（Docker），没有归还的原因是为了提高jvm的性能，假如每GC一次就归还给操作系统，那么以后需要堆内存了还是会向操作系统申请，如此往复。。。

 

说明：

1.使用java -jar jca4.jar工具打开的javacore文件发现有一个Bug

文本编辑器打开显示Object Memory in use

 

 

java -jar jca4.jar打开javacore文件显示的Used Memory，此处通过多个环境取多个javacore文件对比发现，Used Memory取值永远为Total memory。实际值应取上图的 Total memory in use。用到这部分内容分析时需要注意

 

2.

Paas监控上看到的是docker stats的内存。

打堆得内存是jvm的，并且经过了full gc，永远处于最小内存状态。而jvm运行的过程中实际已经向操作系统申请过更大的内存了，这个更大的内存并没有随着full gc而归还给操作系统，所以从Paas平台看到的内存是Jvm曾经使用过的最大内存，就没有降下来

 

 

   openj9 VM说明文档，建议下载查看