记一次JVM调优

前言

我们的游戏上线之初，经常有玩家反馈卡，或者有网络延迟等现象，造成用户流失等现象，这时候我就想到是不是可能是之前的jvm配置有问题，或者存在内存泄露等问题。

现象

• 登入生产环境，使用命令,因为这时候并没有打gc的log，所以只能观察现象。

  jstat -gcutil 27084 250 20

  查看gc状态
  

说明：

S0	S1	E	O	P	YGC	YGCT	FGC	FGCT	GCT
54.62	0.00	42.87	43.52	86.24	1792	5.093	33	7.670	12.763

S0:新生代的susvivor0区，空间使用率为54..62%

S1:新生代的susvivor1区，空间使用率为0.00%(因为还没有执行第二次minor收集)

E:eden区，空间使用率42.87%

O:旧生代，空间使用率43.52%

P:持久带，空间使用率86.24%

YGC:minor gc执行次数1792次

YGCT:minor gc耗费的时间5.093毫秒

FGC:full gc执行次数33

FGCT:full gc耗费的时间7.670毫秒

GCT:gc耗费的总时间12.763毫秒

• 发现其实主要是full gc频率过高，为什么会导致这个原因呢，我首先想到的是是不是老生代分配的过低，就着手分配老生代的比例

• 然而并没有解决这个问题，发现YGC持续升高，而FGC也会逐渐上来，暂时解决了问题的表象而已。

解决问题

首先看一下该jvm使用内存的情况

使用命令jstat -gccapacity:可以显示，VM内存中三代（young,old,perm）对象的使用和占用大小，如：PGCMN显示的是最小perm的内存使用量，PGCMX显示的是perm的内存最大使用量，PGC是当前新生成的perm内存占用量，PC是但前perm内存占用量。其他的可以根据这个类推， OC是old内纯的占用量。

发现问题

看了一下jvm内存分配情况，发现一共新生代只分配了50M左右，发现原来之前使用的启动脚本并没有设置jvm启动参数

解决问题

先把Jvm参数调整，gc log文件夹设置

JAVA_OPTS="-Xms2048m -Xmx2048m -XX:PermSize=64m -XX:MaxPermSize=256m
-verbose:gc -Xloggc:/home/admin/logs/gc.log"

生产环境Java应用的jvm参数Xms与Xmx保持一致，避免因所使用的Java堆内存不够导致频繁full gc以及full gc中因动态调节Java堆大小而耗费延长其周期。
查看下图，FGC已经明显下降到正常水平

总结

学好JVM可以从JVM参数开始：

参数名称	含义 默认值
-Xms	初始堆大小 物理内存的1/64(<1GB) 默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制.
-Xmx	最大堆大小 物理内存的1/4(<1GB) 默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到 -Xms的最小限制
-Xmn	年轻代大小(1.4or lator)注意：此处的大小是（eden+ 2 survivor space).与jmap -heap中显示的New gen是不同的。整个堆大小=年轻代大小 + 年老代大小 + 持久代大小.增大年轻代后,将会减小年老代大小.此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8
-XX:NewSize	设置年轻代大小(for 1.3/1.4)
-XX:MaxNewSize	年轻代最大值(for 1.3/1.4)
-XX:PermSize	设置持久代(perm gen)初始值 物理内存的1/64
-XX:MaxPermSize	设置持久代最大值 物理内存的1/4
-Xss	每个线程的堆栈大小,JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K.更具应用的线程所需内存大小进行 调整.在相同物理内存下,减小这个值能生成更多的线程.但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右,一般小的应用， 如果栈不是很深， 应该是128k够用的 大的应用建议使用256k。这个选项对性能影响比较大，需要严格的测试。（校长）和threadstacksize选项解释很类似,官方文档似乎没有解释,在论坛中有这样一句话:"”-Xss is translated in a VM flag named ThreadStackSize”一般设置这个值就可以了。
-XX:ThreadStackSize	Thread Stack Size (0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]
-XX:NewRatio	年轻代(包括Eden和两个Survivor区)与年老代的比值(除去持久代) -XX:NewRatio=4表示年轻代与年老代所占比值为1:4,年轻代占整个堆栈的1/5Xms=Xmx并且设置了Xmn的情况下，该参数不需要进行设置。
-XX:SurvivorRatio	Eden区与Survivor区的大小比值 设置为8,则两个Survivor区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10
-XX:LargePageSizeInBytes	内存页的大小不可设置过大， 会影响Perm的大小 =128m
-XX:+UseFastAccessorMethods	原始类型的快速优化
-XX:+DisableExplicitGC	关闭System.gc() 这个参数需要严格的测试
-XX:MaxTenuringThreshold	垃圾最大年龄 如果设置为0的话,则年轻代对象不经过Survivor区,直接进入年老代. 对于年老代比较多的应用,可以提高效率.如果将此值设置为一个较大值,则年轻代对象会在Survivor区进行多次复制,这样可以增加对象再年轻代的存活 时间,增加在年轻代即被回收的概率,该参数只有在串行GC时才有效.
-XX:+AggressiveOpts	加快编译
-XX:+UseBiasedLocking	锁机制的性能改善
-Xnoclassgc	禁用垃圾回收
-XX:SoftRefLRUPolicyMSPerMB	每兆堆空闲空间中SoftReference的存活时间 1s softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap
-XX:PretenureSizeThreshold	对象超过多大是直接在旧生代分配 0 单位字节 新生代采用Parallel Scavenge GC时无效,另一种直接在旧生代分配的情况是大的数组对象,且数组中无外部引用对象.
-XX:TLABWasteTargetPercent	TLAB占eden区的百分比 1%
-XX:+CollectGen0First	FullGC时是否先YGC false