然后在该文件中添加为
JAVA_OPTS="-Xms128m -Xmx256m -Xmn100m -XX:MaxPermSize=30m -Xloggc:/usr/local/tomcat/logs/gc.$$.log"
gc开启完成之后,只要启动了tomcat之后,就可目录下生成了gc的log的日志内容。
为了能方便中进行分析的话,需要把Linux中gc日志拷贝到windows本地种。
进行打开hpjtune的jar的文件,来分析gc的文件。
打开了hpjtune的之后,点击打开文件,
浏览gc的日志的文件,并选中之后,点击打开。
这样话可以分析gc的具体的内容了。
要查看GC日志首先要知道GC的log放在哪里,使用jps命令查看当前有哪些java进程在运行,找到我们要查看的java程序的进程pid
使用命令jinfo pid 来查看这个进程对应的java 信息,可以看到大概在最下面的地方有个参数-Xloggc:,他对应的就是gc log的位置。
用gcviewer 打开gc log可以很直观的查看gc log:
第一个标签页就是Chart,这也是最可以直观看出有没有问题的地方,如上图所示,这个日志反应了gc一直在不停的做新生带的回收,并且老年代的使用率一直在增加。图中整个高度为JVM总的内存大小,也就是989.9M,从右侧的Summary也可以看出。其中的紫色部分为老年代的大小,黄色部分是新生带的大小。不同颜色的线和图块的含义可以从菜单看出,如下图:
第二个tab是Event Dtails,可以看出各种GC的次数和时间间隔,以及效果:
可以通过在java命令种加入参数来指定对应的gc类型,打印gc日志信息并输出至文件等策略。GC的日志是以替换的方式(>)写入的,而不是追加(>>),如果下次写入到同一个文件中的话,以前的GC内容会被清空。
启动命令:
结果:
也是一次minor gc,但是与前两次的gc原因不一样,这次的gc原因是:[Metadata GC Threshold],Metadata即元数据的意思,我们可以看出这是与虚拟机的元数据区有关系的一次gc元数据区,在jdk1.8以前又叫永久代,从JDK8开始,永久代(PermGen)的概念被废弃掉了,取而代之的就是这里的称为Metaspace的存储空间元空间和永久代是虚拟机对方法区这个概念的一个具体实现对于元空间而言,这一块空间是存在本地内存当中的,因此,默认情况下,元空间的大小仅受本地内存限制,但我们可以通过参数来指定元空间的大小
这里元空间发生gc,说明元空间的内存不够了,到达了阀值对元空间进行了一次垃圾回收,回收之前是245183K,回收之后是3769K
在元空间gc之后,紧接着发生了一次Full GC,且触发原因也是元空间不足
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)