记录一次Metaspace扩容引发FGC的调优总结

开始之前

  在开始之前先记录一个我碰到的jvm调优的坑。那就是…

为啥我配置到idea64exe.vmoptions中的参数没有生效???

  由于之前一直是在mac上开发,本地开发时当需要优化jvm参数的时候直接去idea的安装目录里修改idea.vmoptions就可以了,换到windows以后想当然的也这么改,但是发现似乎我配置的参数并没有生效, what‘s the f***?探索了一番终于发现了问题所在。

  windows是基于用户登录的,idea会为每个用户在当前用户根目录下创建一份配置信息,所以在idea安装目录下修改idea.vmoptions是不生效的,如图:

  不知道管理员用户登录的话是不是就可以直接修改idea安装目录的ideaexe.vmoptions了,有一个很简单的方法判断你当前的idea项目使用的是哪里的配置信息。

发现问题

  ok,现在终于可以优化我们的jvm参数了,下面是一套我经常用的参数,在我以前开发的时候基本都是用这套参数,我也就直接复制到了idea64exe.vmoptions。

-Xms1024m
-Xmx1024m
-Xmn512m
-XX:MetaspaceSize=256m
-XX:MaxMetaspaceSize=256m
-XX:ReservedCodeCacheSize=512m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow

  保存重启idea以后,开一个项目,嗯,没啥感觉,一切正常。开两个项目,嗯,怎么有点卡呢。又开了一个项目,噩梦开始了,idea开始爆卡,点一下卡2s的那种。

定位原因

  1. jps:查看idea platform的进程ID

  2. jstat -gcutil pid 3s:查看进程垃圾回收情况

 

  从上图可以看出,刚开始YGC和FGC都很健康,但随着我打开的项目越来越多,FGC开始飙升,直接导致了页面明显的卡顿,我试着关掉了几个项目,只保留一个,FGC慢慢变小,分析上图可以看出,M的占比随着FGC略有下降,从93.7%下降到93.2%左右,推测可能是Metaspace扩容导致的FGC。

确认原因

  通过jstat -gc pid 3s:可以查看metaspace具体使用情况,下图可以看出metaspace发生了扩容。

  更简单的是,通过命令jvisualvm,打开Java VisualVM查看mataspace具体使用大小。

  果然,当我同时打开多个项目时,metaspace发生了扩容,并且最终mataspace的使用量达到了接近250M,几乎达到了上面我配置的参数-XX:MetaspaceSize=256m,于是我将上面配置中关于mataspace的参数删掉。

-Xms1024m
-Xmx1024m
-Xmn512m
-XX:ReservedCodeCacheSize=512m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow

   再次jstat -gcutil pid 3s查看GC情况。

  这次FGC情况大有改善,随着我开的项目越来越多,FGC也只是从6次涨到了8次。至此,问题基本就解决了,但如果只是这样的话,我写这篇笔记的意义就不大了,接下来的才是重点。

深入探究

  我尝试重新添加了mataspace的参数,如下:

-Xms1024m
-Xmx1024m
-Xmn512m
-XX:MetaspaceSize=384m
-XX:MaxMetaspaceSize=384m
-XX:ReservedCodeCacheSize=512m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow

 

  再次jstat -gcutil pid 3s查看GC情况:

  上图是我同时开了5个项目的GC情况,FGC只有1次,这才是让我觉得困惑的地方,也就是说当我设置了MetaspaceSize=384m和不设置的时候,是有区别的,在网上看了很多关于mataspace的文章,我发现自己一直以来都没有搞懂-XX:MetaspaceSize=256M的真正含义,这个配置的含义并不是初始化元数据区大小为256m,而仅仅表示的是触发FGC的阈值,至于配置和不配置的区别,也就很明显了,这个知识点在书上看到过但是没放在心上,在实际碰到问题的时候才恍然大悟。

  Metaspace由于使用不断扩容到-XX:MetaspaceSize参数指定的量,就会发生FGC;且之后每次Metaspace扩容都可能会发生FGC。

  我们知道Metapsace是在jdk8中引入的,之前叫permGen,就是我们所说的永久代。在jdk8以前,我们配置-XX:PermSize=256m,那就是说初始化一块256m的内存作为永久代。但是mataspace就不一样了,很明显,mataspace要比perm高级的多。

总结

  • 如果没有配置-XX:MetaspaceSize,那么触发FGC的阈值是21807104(约20.8m)。

  • 如果配置了-XX:MetaspaceSize,那么触发FGC的阈值就是配置的值。

  • 配置比不配置好,实际开发时,可以先开几个项目查看一下metaspace大概占用多少内存,这个跟项目大小和复杂度有关,再根据实际情况配置-XX:MetaspaceSize。

查看当前java进程,一般用来查找进程ID(PID)

  • jps:查看当前java进程及PID
  • jps -l:输出主类或者jar的完全路径名
  • jps -v:输出jvm参数

动态查看gc情况

  • jstat -gc pid 3s: 每隔3s打印当前pid进程的堆内存详细信息
  • jstat -gcutil pid 3s: 每隔3s打印当前pid进程的堆内存总体GC统计信息

可视化工具jvisualvm

  命令行直接输入jvisualvm可打开可视化工具,动态查看java进程内部详细信息

结合以上3种途径,可以查看java进程的详细使用情况和GC情况。

posted @ 2019-10-17 18:08  冬至饮雪  阅读(...)  评论(...编辑  收藏