在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说明文档,建议下载查看