JVM 调优及调优实例.docx

JVM 调优及调优实例.docx

《JVM 调优及调优实例.docx》由会员分享，可在线阅读，更多相关《JVM 调优及调优实例.docx（17页珍藏版）》请在冰豆网上搜索。

JVM调优及调优实例

GC策略&内存申请、对象衰老

JVM里的GC（GarbageCollection）的算法有很多种，如标记清除收集器，压缩收集器，分代收集器等等,详见HotSpotVMGC的种类

现在比较常用的是分代收集（generationalcollection,也是SUNVM使用的,J2SE1.2之后引入），即将内存分为几个区域，将不同生命周期的对象放在不同区域里:

younggeneration，tenuredgeneration和permanetgeneration。

绝大部分的objec被分配在younggeneration（生命周期短），并且大部分的object在这里die。

当younggeneration满了之后，将引发minorcollection（YGC）。

在minorcollection后存活的object会被移动到tenuredgeneration（生命周期比较长）。

最后，tenuredgeneration满之后触发majorcollection。

majorcollection（Fullgc）会触发整个heap的回收，包括回收younggeneration。

permanetgeneration区域比较稳定，主要存放classloader信息。

younggeneration有eden、2个survivor区域组成。

其中一个survivor区域一直是空的，是eden区域和另一个survivor区域在下一次copycollection后活着的objecy的目的地。

object在survivo区域被复制直到转移到tenured区。

我们要尽量减少Fullgc的次数（tenuredgeneration一般比较大,收集的时间较长,频繁的Fullgc会导致应用的性能收到严重的影响）。

堆内存GC

JVM（采用分代回收的策略），用较高的频率对年轻的对象（younggeneration）进行YGC，而对老对象（tenuredgeneration）较少（tenuredgeneration满了后才进行）进行FullGC。

这样就不需要每次GC都将内存中所有对象都检查一遍。

非堆内存不GC

GC不会在主程序运行期对PermGenSpace进行清理，所以如果你的应用中有很多CLASS（特别是动态生成类，当然permgenspace存放的内容不仅限于类）的话,就很可能出现PermGenSpace错误。

内存申请、对象衰老过程

一、内存申请过程

1.JVM会试图为相关Java对象在Eden中初始化一块内存区域；

2.当Eden空间足够时，内存申请结束。

否则到下一步；

3.JVM试图释放在Eden中所有不活跃的对象（minorcollection），释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区；

4.Survivor区被用来作为Eden及old的中间交换区域，当OLD区空间足够时，Survivor区的对象会被移到Old区，否则会被保留在Survivor区；

5.当old区空间不够时，JVM会在old区进行majorcollection；

6.完全垃圾收集后，若Survivor及old区仍然无法存放从Eden复制过来的部分对象，导致JVM无法在Eden区为新对象创建内存区域，则出现"Outofmemory错误"；

二、对象衰老过程

1.新创建的对象的内存都分配自eden。

Minorcollection的过程就是将eden和在用survivorspace中的活对象copy到空闲survivorspace中。

对象在younggeneration里经历了一定次数（可以通过参数配置）的minorcollection后，就会被移到oldgeneration中，称为tenuring。

2.GC触发条件

GC类型

触发条件

触发时发生了什么

注意

查看方式

YGC

eden空间不足

清空Eden+fromsurvivor中所有noref的对象占用的内存将eden+fromsur中所有存活的对象copy到tosur中一些对象将晋升到old中:

  tosur放不下的存活次数超过turningthreshold中的重新计算tenuringthreshold（serialparallelGC会触发此项）重新调整Eden和from的大小（parallelGC会触发此项）

全过程暂停应用是否为多线程处理

由具体的GC决定

jstat–gcutil 

gclog

FGC

old空间不足perm空间不足

显示调用System.GC,RMI等的定时触发YGC时的悲观策略dumplive的内存信息时（jmap–dump:

live）

清空heap中noref的对象permgen中已经被卸载的classloader中加载的class信息如配置了CollectGenOFirst,则先触发YGC（针对serialGC）如配置了ScavengeBeforeFullGC,则先触发YGC（针对serialGC）

全过程暂停应用是否为多线程处

理由具体的GC决定是否压缩需要

看配置的具体GC

jstat–gcutil 

gclog

3.permanentgeneration空间不足会引发FullGC,仍然不够会引发PermGenSpace错误。

参考：

JVM参数设置、分析

不管是YGC还是FullGC,GC过程中都会对导致程序运行中中断,正确的选择不同的GC策略,调整JVM、GC的参数，可以极大的减少由于GC工作，而导致的程序运行中断方面的问题，进而适当的提高Java程序的工作效率。

但是调整GC是以个极为复杂的过程，由于各个程序具备不同的特点，如：

web和GUI程序就有很大区别（Web可以适当的停顿，但GUI停顿是客户无法接受的），而且由于跑在各个机器上的配置不同（主要cup个数，内存不同），所以使用的GC种类也会不同（如何选择见GC种类及如何选择）。

本文将注重介绍JVM、GC的一些重要参数的设置来提高系统的性能。

GC性能方面的考虑

对于GC的性能主要有2个方面的指标：

吞吐量throughput（工作时间不算gc的时间占总的时间比）和暂停pause（gc发生时app对外显示的无法响应）。

1.TotalHeap

默认情况下，vm会增加/减少heap大小以维持freespace在整个vm中占的比例，这个比例由MinHeapFreeRatio和MaxHeapFreeRatio指定。

一般而言，server端的app会有以下规则：

•对vm分配尽可能多的memory；

•将Xms和Xmx设为一样的值。

如果虚拟机启动时设置使用的内存比较小，这个时候又需要初始化很多对象，虚拟机就必须重复地增加内存。

•处理器核数增加，内存也跟着增大。

2.TheYoungGeneration

另外一个对于app流畅性运行影响的因素是younggeneration的大小。

younggeneration越大，minorcollection越少；但是在固定heapsize情况下，更大的younggeneration就意味着小的tenuredgeneration，就意味着更多的majorcollection（majorcollection会引发minorcollection）。

NewRatio反映的是young和tenuredgeneration的大小比例。

NewSize和MaxNewSize反映的是younggeneration大小的下限和上限，将这两个值设为一样就固定了younggeneration的大小（同Xms和Xmx设为一样）。

如果希望，SurvivorRatio也可以优化survivor的大小，不过这对于性能的影响不是很大。

SurvivorRatio是eden和survior大小比例。

一般而言，server端的app会有以下规则：

•首先决定能分配给vm的最大的heapsize，然后设定最佳的younggeneration的大小；

•如果heapsize固定后，增加younggeneration的大小意味着减小tenuredgeneration大小。

让tenuredgeneration在任何时候够大，能够容纳所有live的data（留10%-20%的空余）。

经验&&规则

1.年轻代大小选择

•响应时间优先的应用:

尽可能设大,直到接近系统的最低响应时间限制（根据实际情况选择）.在此种情况下,年轻代收集发生的频率也是最小的.同时,减少到达年老代的对象.

•吞吐量优先的应用:

尽可能的设置大,可能到达Gbit的程度.因为对响应时间没有要求,垃圾收集可以并行进行,一般适合8CPU以上的应用.

•避免设置过小.当新生代设置过小时会导致:

1.YGC次数更加频繁2.可能导致YGC对象直接进入旧生代,如果此时旧生代满了,会触发FGC.

2.年老代大小选择

1.响应时间优先的应用:

年老代使用并发收集器,所以其大小需要小心设置,一般要考虑并发会话率和会话持续时间等一些参数.如果堆设置小了,可以会造成内存碎片,高回收频率以及应用暂停而使用传统的标记清除方式;如果堆大了,则需要较长的收集时间.最优化的方案,一般需要参考以下数据获得:

并发垃圾收集信息、持久代并发收集次数、传统GC信息、花在年轻代和年老代回收上的时间比例。

2.吞吐量优先的应用:

一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代.原因是,这样可以尽可能回收掉大部分短期对象,减少中期的对象,而年老代尽存放长期存活对象.

3.较小堆引起的碎片问题

因为年老代的并发收集器使用标记,清除算法,所以不会对堆进行压缩.当收集器回收时,他会把相邻的空间进行合并,这样可以分配给较大的对象.但是,当堆空间较小时,运行一段时间以后,就会出现"碎片",如果并发收集器找不到足够的空间,那么并发收集器将会停止,然后使用传统的标记,清除方式进行回收.如果出现"碎片",可能需要进行如下配置:

-XX:

+UseCMSCompactAtFullCollection:

使用并发收集器时,开启对年老代的压缩.

-XX:

CMSFullGCsBeforeCompaction=0:

上面配置开启的情况下,这里设置多少次FullGC后,对年老代进行压缩

4.用64位操作系统，Linux下64位的jdk比32位jdk要慢一些，但是吃得内存更多，吞吐量更大

5.XMX和XMS设置一样大，MaxPermSize和MinPermSize设置一样大，这样可以减轻伸缩堆大小带来的压力

6.使用CMS的好处是用尽量少的新生代，经验值是128M－256M，然后老生代利用CMS并行收集，这样能保证系统低延迟的吞吐效率。

实际上cms的收集停顿时间非常的短，2G的内存，大约20－80ms的应用程序停顿时间

7.系统停顿的时候可能是GC的问题也可能是程序的问题，多用jmap和jstack查看，或者killall-3java，然后查看java控制台日志，能看出很多问题。

（相关工具的使用方法将在后面的blog中介绍）

8.仔细了解自己的应用，如果用了缓存，那么年老代应该大一些，缓存的HashMap不应该无限制长，建议采用LRU算法的Map做缓存，LRUMap的最大长度也要根据实际情况设定。

9.采用并发回收时，年轻代小一点，年老代要大，因为年老大用的是并发回收，即使时间长点也不会影响其他程序继续运行，网站不会停顿

10.JVM参数的设置（特别是–Xmx–Xms–Xmn-XX:

SurvivorRatio-XX:

MaxTenuringThreshold等参数的设置没有一个固定的公式，需要根据PVold区实际数据YGC次数等多方面来衡量。

为了避免promotionfaild可能会导致xmn设置偏小，也意味着YGC的次数会增多，处理并发访问的能力下降等问题。

每个参数的调整都需要经过详细的性能测试，才能找到特定应用的最佳配置。

promotionfailed:

垃圾回收时promotionfailed是个很头痛的问题，一般可能是两种原因产生，第一个原因是救助空间不够，救助空间里的对象还不应该被移动到年老代，但年轻代又有很多对象需要放入救助空间；第二个原因是年老代没有足够的空间接纳来自年轻代的对象；这两种情况都会转向FullGC，网站停顿时间较长。

解决方方案一：

第一个原因我的最终解决办法是去掉救助空间，设置-XX:

SurvivorRatio=65536-XX:

MaxTenuringThreshold=0即可，第二个原因我的解决办法是设置CMSInitiatingOccupancyFraction为某个值（假设70），这样年老代空间到70%时就开始执行CMS，年老代有足够的空间接纳来自年轻代的对象。

解决方案一的改进方案：

又有改进了，上面方法不太好，因为没有用到救助空间，所以年老代容易满，CMS执行会比较频繁。

我改善了一下，还是用救助空间，但是把救助空间加大，这样也不会有promotionfailed。

具体操作上，32位Linux和64位Linux好像不一样，64位系统似乎只要配置MaxTenuringThreshold参数，CMS还是有暂停。

为了解决暂停问题和promotionfailed问题，最后我设置-XX:

SurvivorRatio=1，并把MaxTenuringThreshold去掉，这样即没有暂停又不会有promotoinfailed，而且更重要的是，年老代和永久代上升非常慢（因为好多对象到不了年老代就被回收了），所以CMS执行频率非常低，好几个小时才执行一次，这样，服务器都不用重启了。

-Xmx4000M-Xms4000M-Xmn600M-XX:

PermSize=500M-XX:

MaxPermSize=500M-Xss256K-XX:

+DisableExplicitGC-XX:

SurvivorRatio=1-XX:

+UseConcMarkSweepGC-XX:

+UseParNewGC-XX:

+CMSParallelRemarkEnabled-XX:

+UseCMSCompactAtFullCollection-XX:

CMSFullGCsBeforeCompaction=0-XX:

+CMSClassUnloadingEnabled-XX:

LargePageSizeInBytes=128M-XX:

+UseFastAccessorMethods-XX:

+UseCMSInitiatingOccupancyOnly-XX:

CMSInitiatingOccupancyFraction=80-XX:

SoftRefLRUPolicyMSPerMB=0-XX:

+PrintClassHistogram-XX:

+PrintGCDetails-XX:

+PrintGCTimeStamps-XX:

+PrintHeapAtGC-Xloggc:

log/gc.log

CMSInitiatingOccupancyFraction值与Xmn的关系公式

上面介绍了promontionfaild产生的原因是EDEN空间不足的情况下将EDEN与Fromsurvivor中的存活对象存入Tosurvivor区时,Tosurvivor区的空间不足，再次晋升到oldgen区，而oldgen区内存也不够的情况下产生了promontionfaild从而导致fullgc.那可以推断出：

eden+fromsurvivor

（Xmx-Xmn）*（1-CMSInitiatingOccupancyFraction/100）>=（Xmn-Xmn/（SurvivorRatior+2））进而推断出：

CMSInitiatingOccupancyFraction<=（（Xmx-Xmn）-（Xmn-Xmn/（SurvivorRatior+2）））/（Xmx-Xmn）*100

例如：

当xmx=128xmn=36SurvivorRatior=1时CMSInitiatingOccupancyFraction<=（（128.0-36）-（36-36/（1+2）））/（128-36）*100=73.913

当xmx=128xmn=24SurvivorRatior=1时CMSInitiatingOccupancyFraction<=（（128.0-24）-（24-24/（1+2）））/（128-24）*100=84.615…

当xmx=3000xmn=600SurvivorRatior=1时CMSInitiatingOccupancyFraction<=（（3000.0-600）-（600-600/（1+2）））/（3000-600）*100=83.33

CMSInitiatingOccupancyFraction低于70%需要调整xmn或SurvivorRatior值。

参考：

JAVAHOTSPOTVM（

JVM几个重要的参数 （校长）

javajvm参数-Xms-Xmx-Xmn-Xss调优总结

JavaHotSpotVMOptions

FrequentlyAskedQuestionsAbouttheJavaHotSpotVM

JavaSEHotSpotataGlance

Java性能调优笔记（内附测试例子很有用）

说说MaxTenuringThreshold这个参数

生产环境参数实例及分析

javaapplication项目（非web项目）

改进前：

-Xms128m

-Xmx128m

-XX:

NewSize=64m

-XX:

PermSize=64m

-XX:

+UseConcMarkSweepGC

-XX:

CMSInitiatingOccupancyFraction=78

-XX:

ThreadStackSize=128

-Xloggc:

logs/gc.log

-Dsun.rmi.dgc.server.gcInterval=3600000

-Dsun.rmi.dgc.client.gcInterval=3600000

-Dsun.rmi.server.exceptionTrace=true

问题:

1.permsize设置较小,很容易达到报警范围（0.8）

2.没有设置MaxPermSize，堆增长会带来额外压力。

3.NewSize较大，oldgen剩余空间64m，一方面可能会带来old区容易增长到报警范围（监控数据显示oldgenused长期在50m左右，接近78%，容易出现fullgc）,另一方面也存在promontionfail风险

改进后：

-Xms128m

-Xmx128m

-Xmn24m

-XX:

PermSize=80m

-XX:

MaxPermSize=80m

-Xss256k

-XX:

SurvivorRatio=1

-XX:

MaxTenuringThreshold=20

-XX:

+UseParNewGC

-XX:

+UseConcMarkSweepGC

-XX:

CMSInitiatingOccupancyFraction=75

-XX:

+UseCMSCompactAtFullCollection

-XX:

+CMSParallelRemarkEnabled

-XX:

CMSFullGCsBeforeCompaction=2

-XX:

SoftRefLRUPolicyMSPerMB=0

-XX:

+PrintClassHistogram

-XX:

+PrintGCDetails

-XX:

+PrintGCTimeStamps

-XX:

+PrintHeapAtGC

-Xloggc:

logs/gc.log

-Dsun.rmi.dgc.server.gcInterval=3600000

-Dsun.rmi.dgc.client.gcInterval=3600000

-Dsun.rmi.server.exceptionTrace=true

修改点：

1.PermSize与MaxPermSize都设置为80，一方面避免nonheapwarn（报警阀值0.8非对内存一般占用到60M以内），一方面避免堆伸缩带来的压力

2.通过设置Xmn=24M及SurvivorRatio=1使得Eden区=fromspace=tospace=8M,降低了Eden区大小，降低YGC的时间（降低到3-4ms左右）,同时通过设MaxTenuringThreshold=20，使得oldgen的增长很缓慢。

带来的问题是YGC的次数明显提高了很多。

3.其他参数优化修改后带来的好处见JVM参数设置

再次改进后

-Xms128m

-Xmx128m

-Xmn36m

-XX:

PermSize=80m

-XX:

MaxPermSize=80m

-Xss256k

-XX:

SurvivorRatio=1

-XX:

MaxTenuringThreshold=20

-XX:

+UseParNewGC

-XX:

+UseConcMarkSweepGC

-XX:

CMSInitiatingOccupancyFraction=73

-XX:

+UseCMSCompactAtFullCollection

-XX:

+CMSParallelRemarkEnabled

-XX:

CMSFullGCsBeforeCompaction=2

-XX:

SoftRefLRUPolicyMSPerMB=0

-XX:

+PrintClassHistogram

-XX:

+PrintGCDetails

-XX:

+PrintGCTimeStamps

-XX:

+PrintHeapAtGC

-Xloggc:

logs/gc.log

-Dsun.rmi.dgc.server.gcInterval=3600000

-Dsun.rmi.dgc.client.gcInterval=3600000

-Dsun.rmi.server.exceptionTrace=true

修改点：

在上面的基础上调整Xmn大小到36M，设置CMSInitiatingOccupancyFraction=73。

Dden区与Survivor区大小都增加到12M，通过CMSInitiatingOccupancyFraction计算公式,计算得出value为73是，可以避免promotionfaild问题，同时满足堆内存监控报警值在80%：

内存大小128M*80%=102.4M102.4M-36M=66.4M（老生代达到此值报警）老生代达到67