cms优化之晋升失败
博客专区 > Mr_Qi 的博客 > 博客详情
cms优化之晋升失败
Mr_Qi 发表于3个月前
cms优化之晋升失败
  • 发表于 3个月前
  • 阅读 133
  • 收藏 3
  • 点赞 0
  • 评论 0

腾讯云 十分钟定制你的第一个小程序>>>   

背景

最近系统的用户使用越来越多,随之而来的情况导致系统在运行一段时间后开始出现fgc(频次大约1天2次),cms作为高响应速度的collector,一般我们会尽量避免出现remark或者尽量减低remark的时间(remark阶段会出现stop the world)

我们关注一下zabbix的内存监控图

注:系统为jdk7

如上两张图分别对应堆内存的使用和老年代的使用

从上图可以看出,基本上minor gc比较频繁(第一张的锯齿),并没有出现内存泄露(第一张图在fgc的回收下内存占用几乎不变)

那么出现一次较大的fgc的原因是什么呢?

我们参看一下当前系统的情况

小知识,cms在一次remark前后各算一次fgc

基本看出老年代使用并不高,而年轻代比较小,伊甸园去仅为209m ,幸存者区域约为26m(换句话说,一次晋升最多可能晋升26+209M)

我们看到此次晋升失败,而老年代从2.3g直接fullgc到了500m,存在1.8g的内存回收。中断时间约为2.69s

初步考虑内存分配不合理导致年轻代过小,出现多次的minor gc(minor gc的频率直接决定了对象的年龄,而年龄又决定了晋升到老年代的时机)-XX:MaxTenuringThreshold 最大为15

查看一下我们的jvm参数

 /usr/java/jdk1.7.0_80/bin/java -Djava.util.logging.config.file=/mnt/apache-tomcat-7.0.70-erp/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djdk.tls.ephemeralDHKeySize=2048 -Xms2048m -Xmx3072m -XX:PermSize=128m -XX:MaxNewSize=256m -XX:MaxPermSize=256m -XX:ParallelGCThreads=4 -XX:+UseConcMarkSweepGC -Xloggc:/mnt/apache-tomcat-7.0.70-erp/logs/gc.log -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+DisableExplicitGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/mnt/apache-tomcat-7.0.70-erp -Djava.endorsed.dirs=/mnt/apache-tomcat-7.0.70-erp/endorsed -classpath /mnt/apache-tomcat-7.0.70-erp/bin/bootstrap.jar:/mnt/apache-tomcat-7.0.70-erp/bin/tomcat-juli.jar -Dcatalina.base=/mnt/apache-tomcat-7.0.70-erp -Dcatalina.home=/mnt/apache-tomcat-7.0.70-erp -Djava.io.tmpdir=/mnt/apache-tomcat-7.0.70-erp/temp org.apache.catalina.startup.Bootstrap start

WTF 居然设置了-XX:MaxNewSize为256m,那么默认的surviorRatio为8 也就是 s0=25.6m s1=25.6m eden=204.8m 

为了减低cms在gc时remark时间 考虑调大年轻代,这样对象分配时在年轻代,由于年轻代足够大,不会频繁发生minor gc,这样对象的年龄不会变大的太快。所以需要设置合理的newRatio。

export CATALINA_OPTS="$CATALINA_OPTS -Xms2048m -Xmx3072m -XX:PermSize=128m -XX:NewRatio=3 -XX:MaxPermSize=256m -XX:CMSInitiatingOccupancyFraction=72 -XX:ParallelGCThreads=4 -XX:+UseConcMarkSweepGC -Xloggc:/mnt/apache-tomcat-7.0.70-erp/logs/gc.log -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+DisableExplicitGC  -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/mnt/apache-tomcat-7.0.70-erp"

将年轻代设置为512m~768m

同时加上-XX:CMSInitiatingOccupancyFraction

该参数表示在老年代达到72%时将强行发生fgc,优先回收内存,以防止出现年轻代晋升失败的情况。

年轻代晋升失败条件如下(不考虑内存碎片):

幸存者+伊甸园区<老年代剩余

采用默认比例 surviorRatio 为8 

此处newRatio为3

公式为

(1+surviorRatio)/(2+surviorRatio)*new <=old*(1-CMSInitiatingOccupancyFraction/100)

得出CMSInitiatingOccupancyFraction约为70 此处使用72(经验值)

原先设置年轻代大小应该是老的jvm参数,当修改了xmx之后没有更新该值,导致年轻代过小

因此此处考虑使用ratio

以观后效

经过改造 目前zabbix的内存使用图如下(最后一天)

基本上可以在老年代达到一定容量时就回收掉,同时stw时间明显降低

原来统计从运行3天暂停8s降低 到运行1天 暂停0.082s

younggc的频率也有所下降,时间也缩短。

共有 人打赏支持
粉丝 133
博文 145
码字总数 139099
×
Mr_Qi
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: