文档章节

JVM fullgc 调优实践

j
 johnli
发布于 2016/09/26 15:37
字数 876
阅读 39
收藏 3

场景:生产环境使用的是Thrift提供的rpc接口服务,在做接口性能测试的时候,监控了JVM内存使用情况;

1.通过定时检查jvm gc情况,发现fullgc触发的频率特别频繁,一分钟会有好几次的fullgc,以下为监控数据

[root@wangfw-smarttrip-dev-7 ~]# jstat -gcutil 18154
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
  0.00  64.20  88.06  55.23  29.84    427    6.259     3    0.986    7.245
[root@wangfw-smarttrip-dev-7 ~]# jstat -gcutil 18154
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
 92.97   0.00  18.90  96.18  29.87    734   11.218     7    1.568   12.787
[root@wangfw-smarttrip-dev-7 ~]# jstat -gcutil 18154
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
  0.00  90.62  66.76  98.61  29.87    737   11.275     7    1.568   12.843
[root@wangfw-smarttrip-dev-7 ~]# jstat -gcutil 18154
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
 65.62   0.00  95.33  50.56  29.87    834   12.845     9    1.904   14.749
[root@wangfw-smarttrip-dev-7 ~]# jstat -gcutil 18154
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
  0.00  81.88  11.37  62.45  29.87    849   13.101     9    1.904   15.005
[root@wangfw-smarttrip-dev-7 ~]# jstat -gcutil 18154
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
 87.50   0.00  95.45  65.11  29.87   1198   18.710    13    2.576   21.286
[root@wangfw-smarttrip-dev-7 ~]# jstat -gcutil 18154
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
 85.94   0.00  19.50  49.17  29.82   1664   26.114    18    3.472   29.586
[root@wangfw-smarttrip-dev-7 ~]# jstat -gcutil 18154
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
  0.00  59.38  12.04  58.32  29.82   2227   35.113    23    4.326   39.439

2.然后通过jmap -heap pid 打印了对应的内存情况,发现老年代的内存大小较小;

Heap Configuration:
   MinHeapFreeRatio = 0
   MaxHeapFreeRatio = 100
   MaxHeapSize      = 1073741824 (1024.0MB)
   NewSize          = 1310720 (1.25MB)
   MaxNewSize       = 17592186044415 MB
   OldSize          = 5439488 (5.1875MB)
   NewRatio         = 2
   SurvivorRatio    = 8
   PermSize         = 134217728 (128.0MB)
   MaxPermSize      = 134217728 (128.0MB)
   G1HeapRegionSize = 0 (0.0MB)

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 349700096 (333.5MB)
   used     = 295902608 (282.19471740722656MB)
   free     = 53797488 (51.30528259277344MB)
   84.61610716858368% used
From Space:
   capacity = 4194304 (4.0MB)
   used     = 3932160 (3.75MB)
   free     = 262144 (0.25MB)
   93.75% used
To Space:
   capacity = 4194304 (4.0MB)
   used     = 0 (0.0MB)
   free     = 4194304 (4.0MB)
   0.0% used
PS Old Generation
   capacity = 125829120 (120.0MB)
   used     = 84266376 (80.36267852783203MB)
   free     = 41562744 (39.63732147216797MB)
   66.96889877319336% used
PS Perm Generation
   capacity = 134217728 (128.0MB)
   used     = 40088296 (38.231178283691406MB)
   free     = 94129432 (89.7688217163086MB)
   29.86810803413391% used

原因分析:

     新生代经过几个步骤之后一直在往老年代转移,由于老年的的内存区域较小,达到临界点的时候直接就触发了fullgc;

解决方法:

java -Xms1024m -Xmx1024m -Xmn728m -XX:PermSize=128m 
-Xmn728m:设置年轻代大小为728m。整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小;

主要需要搞明白分代垃圾回收流程

大部分对象在Eden区中生成。当Eden区满时,还存活的对象将被复制到Survivor区(两个中的一个),当这

个Survivor区满时,此区的存活对象将被复制到另外一个Survivor区,当这个Survivor去也满了的时候,从第

一个Survivor区复制过来的并且此时还存活的对象,将被复制“年老区(Tenured)”。需要注意,Survivor的两个

区是对称的,没先后关系,所以同一个区中可能同时存在从Eden复制过来 对象,和从前一个Survivor复制过

来的对象,而复制到年老区的只有从第一个Survivor去过来的对象。而且,Survivor区总有一个是空的。同

时,根据程序需要,Survivor区是可以配置为多个的(多于两个),这样可以增加对象在年轻代中的存在时

间,减少被放到年老代的可能,这样子就可以控制老年代的大小而不会去触发对应的fullgc

参考文献:

JVM系列详解(经典): http://pengjiaheng.iteye.com/blog/552456

JVM 设置:http://www.open-open.com/lib/view/open1340192635908.html

Eden Old 对象转移详解: http://www.cnblogs.com/Mandylover/p/5208055.html

触发fullgc列子: http://blog.csdn.net/scugxl/article/details/50935863

线上fullgc例子1: http://blog.csdn.net/hengyunabc/article/details/24924843

线上fullgc例子2: http://caogen81.iteye.com/blog/1513345

jvm gc类型: http://www.importnew.com/13827.html

© 著作权归作者所有

j
粉丝 0
博文 7
码字总数 3032
作品 0
程序员
私信 提问
如何合理的规划一次jvm性能调优

这是jvm优化系列第三篇: jvm优化——垃圾回收 jvm优化——监控工具 JVM性能调优涉及到方方面面的取舍,往往是牵一发而动全身,需要全盘考虑各方面的影响。但也有一些基础的理论和原则,理解...

wier
2017/10/25
0
9
JVM系列篇:JVM性能调优的6大步骤,及关键调优参数详解

本系列会持续更新。 一、JVM内存调优 对JVM内存的系统级的调优主要的目的是减少GC的频率和Full GC的次数。 1.Full GC 会对整个堆进行整理,包括Young、Tenured和Perm。Full GC因为需要对整个...

mikechen优知
03/26
0
0
Java编程——jvm优化之 图解垃圾回收

从这篇开始我们探讨一些jvm调优的问题。在jvm调优中一个离不开的重点是垃圾回收,当垃圾回收成为系统达到更高并发量的瓶颈时,我们就需要对jvm中如果进行“自动化”垃圾回收技术实施必要的监...

远方的梦Java
2018/08/06
0
0
成为Java GC专家(5)—Java性能调优原则

这是“成为Java GC专家”系列的第五篇文章。在第一篇深入浅出Java垃圾回收机制中,我们已经学习了不同的GC算法流程、GC的工作原理、新生代(Young Generation)和老年代(Old Generation)的...

stefanzhlg
2014/12/05
0
1
《成神之路-基础篇》JVM——JVM参数及调优(已完结)

Java内存模型,Java内存管理,Java堆和栈,垃圾回收 本文是[《成神之路系列文章》][1]的第一篇,主要是关于JVM的一些介绍。 持续更新中 JVM参数及调优 JVM实用参数系列 成为Java GC专家(5)...

2018/05/05
0
0

没有更多内容

加载失败,请刷新页面

加载更多

js动态设置元素高度

this.$refs.xxx.style.height= this.contentHeight; 元素需要绑定

Carbenson
50分钟前
2
0
今天的学习

今天学到了ci框架中的查询语句的where条件语句: 1、$this->db->select('')->from('')->where('id = ??')->get()->result_array();2、$this->db->select('')->from('')->where('id', '??'......

墨冥
59分钟前
2
0
MySQL在高并发下的订单撮合、系统使用、共享锁与排他锁保证数据一致性

前序 距离上次择文发表,两月余久。2018年也即将要结束了,目前的工作依然是与区块链应用相关的,也很荣幸在9月初受邀签约出版暂名为《区块链以太坊DApp实战开发》一书,预计在明年年初出版。...

我最喜欢三大框架
今天
2
0
深入理解Flutter多线程

该文章属于<简书 — 刘小壮>原创,转载请注明: <简书 — 刘小壮> https://www.jianshu.com/p/54da18ed1a9e Flutter默认是单线程任务处理的,如果不开启新的线程,任务默认在主线程中处理。 ...

刘小壮
今天
3
0
输入n个整数,找出其中最小的K个数。例如输入4,5,1,6,2,7,3,8这8个数字,则最小的4个数字是1,2,3,4,。

//有点投机啦 import java.util.ArrayList; public class Solution { public ArrayList<Integer> GetLeastNumbers_Solution(int [] input, int k) { ArrayList <Integer> s=new ArrayLi......

南桥北木
今天
2
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部