JVM专题：JVM调优优化篇

前言

本文主要介绍具体如何配置JVM参数来达到调优的目的。

GC性能方面的考虑

1. Total Heap

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

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

对vm分配尽可能多的memory；
将Xms和Xmx设为一样的值。如果虚拟机启动时设置使用的内存比较小，这个时候又需要初始化很多对象，虚拟机就必须重复地增加内存。
处理器核数增加，内存也跟着增大。

2. The Young Generation

另外一个对于app流畅性运行影响的因素是young generation的大小。young generation越大，minor collection越少；但是在固定heap size情况下，更大的young generation就意味着小的tenured generation，就意味着更多的major collection(major collection会引发minor collection)。

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

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

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

首先决定能分配给vm的最大的heap size，然后设定最佳的young generation的大小；
如果heap size固定后，增加young generation的大小意味着减小tenured generation大小。让tenured generation在任何时候够大，能够容纳所有live的data（留10%-20%的空余）。

经验&&规则

年轻代大小选择
- 响应时间优先的应用:尽可能设大,直到接近系统的最低响应时间限制(根据实际情况选择).在此种情况下,年轻代收集发生的频率也是最小的.同时,减少到达年老代的对象.
- 吞吐量优先的应用:尽可能的设置大,可能到达Gbit的程度.因为对响应时间没有要求,垃圾收集可以并行进行,一般适合8CPU以上的应用.
- 避免设置过小.当新生代设置过小时会导致:1.YGC次数更加频繁 2.可能导致YGC对象直接进入旧生代,如果此时旧生代满了,会触发FGC.
年老代大小选择
1. 响应时间优先的应用:年老代使用并发收集器,所以其大小需要小心设置,一般要考虑并发会话率和会话持续时间等一些参数.如果堆设置小了,可以会造成内存碎片,高回收频率以及应用暂停而使用传统的标记清除方式;如果堆大了,则需要较长的收集时间.最优化的方案,一般需要参考以下数据获得:
  并发垃圾收集信息、持久代并发收集次数、传统GC信息、花在年轻代和年老代回收上的时间比例。
2. 吞吐量优先的应用:一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代.原因是,这样可以尽可能回收掉大部分短期对象,减少中期的对象,而年老代尽存放长期存活对象.
较小堆引起的碎片问题
因为年老代的并发收集器使用标记,清除算法,所以不会对堆进行压缩.当收集器回收时,他会把相邻的空间进行合并,这样可以分配给较大的对象.但是,当堆空间较小时,运行一段时间以后,就会出现"碎片",如果并发收集器找不到足够的空间,那么并发收集器将会停止,然后使用传统的标记,清除方式进行回收.如果出现"碎片",可能需要进行如下配置:
-XX:+UseCMSCompactAtFullCollection:使用并发收集器时,开启对年老代的压缩.
-XX:CMSFullGCsBeforeCompaction=0:上面配置开启的情况下,这里设置多少次Full GC后,对年老代进行压缩
用64位操作系统，Linux下64位的jdk比32位jdk要慢一些，但是吃得内存更多，吞吐量更大
XMX和XMS设置一样大，MaxPermSize和MinPermSize设置一样大，这样可以减轻伸缩堆大小带来的压力
使用CMS的好处是用尽量少的新生代，经验值是128M－256M，然后老生代利用CMS并行收集，这样能保证系统低延迟的吞吐效率。实际上cms的收集停顿时间非常的短，2G的内存，大约20－80ms的应用程序停顿时间
系统停顿的时候可能是GC的问题也可能是程序的问题，多用jmap和jstack查看，或者killall -3 java，然后查看java控制台日志，能看出很多问题。(相关工具的使用方法将在后面的blog中介绍)
仔细了解自己的应用，如果用了缓存，那么年老代应该大一些，缓存的HashMap不应该无限制长，建议采用LRU算法的Map做缓存，LRUMap的最大长度也要根据实际情况设定。
采用并发回收时，年轻代小一点，年老代要大，因为年老大用的是并发回收，即使时间长点也不会影响其他程序继续运行，网站不会停顿
JVM参数的设置(特别是 –Xmx –Xms –Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold等参数的设置没有一个固定的公式，需要根据PV old区实际数据 YGC次数等多方面来衡量。为了避免promotion faild可能会导致xmn设置偏小，也意味着YGC的次数会增多，处理并发访问的能力下降等问题。每个参数的调整都需要经过详细的性能测试，才能找到特定应用的最佳配置。

promotion failed:

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

解决方方案一：

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

解决方案一的改进方案：

又有改进了，上面方法不太好，因为没有用到救助空间，所以年老代容易满，CMS执行会比较频繁。我改善了一下，还是用救助空间，但是把救助空间加大，这样也不会有promotion failed。具体操作上，32位Linux和64位Linux好像不一样，64位系统似乎只要配置MaxTenuringThreshold参数，CMS还是有暂停。为了解决暂停问题和promotion failed问题，最后我设置-XX:SurvivorRatio=1 ，并把MaxTenuringThreshold去掉，这样即没有暂停又不会有promotoin failed，而且更重要的是，年老代和永久代上升非常慢（因为好多对象到不了年老代就被回收了），所以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的关系公式

上面介绍了promontion faild产生的原因是EDEN空间不足的情况下将EDEN与From survivor中的存活对象存入To survivor区时,To survivor区的空间不足，再次晋升到old gen区，而old gen区内存也不够的情况下产生了promontion faild从而导致full gc.那可以推断出：eden+from survivor < old gen区剩余内存时，不会出现promontion faild的情况，即：
(Xmx-Xmn)*(1-CMSInitiatingOccupancyFraction/100)>=(Xmn-Xmn/(SurvivorRatior+2)) 进而推断出：

CMSInitiatingOccupancyFraction <=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)*100

例如：

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

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

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

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

令：

网上一童鞋推断出的公式是：:(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn 这个公式个人认为不是很严谨，在内存小的时候会影响xmn的计算。

本篇文章基于JVM性能调优，结合JVM的各项参数对应用程序调优，主要内容有以下几个方面：

1、JVM调优的一般流程

2、JVM调优所要关注的几个性能指标

3、JVM调优需要掌握的一些原则

4、调优策略和示例

一、性能调优的层次

　　为了提升系统性能，我们需要对系统的各个角度和层次来进行优化，以下是需要优化的几个层次。

　　从上面我们可以看到，除了JVM调优以外，还有其他几个层面需要来处理，所以针对系统的调优不是只有JVM调优一项，而是需要针对系统来整体调优，才能提升系统的性能。本篇只针对JVM调优来讲解。

在进行JVM调优之前，我们假设项目的架构调优和代码调优已经进行过或者是针对当前项目是最优的。这两个是JVM调优的基础，并且架构调优是对系统影响最大的，我们不能指望一个系统架构有缺陷或者代码层次优化没有穷尽的应用，通过JVM调优令其达到一个质的飞跃，这是不可能的。

另外，在调优之前，必须得有明确的性能优化目标，然后找到其性能瓶颈。之后针对瓶颈的优化，还需要对应用进行压力和基准测试，通过各种监控和统计工具，确认调优后的应用是否已经达到相关目标。

二、`JVM`调优流程

调优的最终目的都是为了令应用程序使用最小的硬件消耗来承载更大的吞吐。JVM的调优也不例外，JVM调优主要是针对垃圾收集器的收集性能优化，令运行在虚拟机上的应用能够使用更少的内存以及延迟获取更大的吞吐量。当然这里的最少是最优的选择，而不是越少越好。

1、性能定义

要查找和评估器性能瓶颈，首先要知道性能定义，对于JVM调优来说，我们需要知道以下三个定义属性，依作为评估基础:

吞吐量：重要指标之一，是指不考虑垃圾收集引起的停顿时间或内存消耗，垃圾收集器能支撑应用达到的最高性能指标。

延迟：其度量标准是缩短由于垃圾啊收集引起的停顿时间或者完全消除因垃圾收集所引起的停顿，避免应用运行时发生抖动。

内存占用：垃圾收集器流畅运行所需要的内存数量。

这三个属性中，其中一个任何一个属性性能的提高，几乎都是以另外一个或者两个属性性能的损失作代价，不可兼得，具体某一个属性或者两个属性的性能对应用来说比较重要，要基于应用的业务需求来确定。

2、性能调优原则

在调优过程中，我们应该谨记以下3个原则，以便帮助我们更轻松的完成垃圾收集的调优，从而达到应用程序的性能要求。

Minor GC回收原则：每次Minor GC都要尽可能多的收集垃圾对象。以减少应用程序发生Full GC的频率。
GC内存最大化原则：处理吞吐量和延迟问题时候，垃圾处理器能使用的内存越大，垃圾收集的效果越好，应用程序也会越来越流畅。
GC调优3选2原则: 在性能属性里面，吞吐量、延迟、内存占用，我们只能选择其中两个进行调优，不可三者兼得。

3、性能调优流程

以上就是对应用程序进行JVM调优的基本流程，我们可以看到，JVM调优是根据性能测试结果不断优化配置而多次迭代的过程。在达到每一个系统需求指标之前，之前的每个步骤都有可能经历多次迭代。有时候为了达到某一方面的指标，有可能需要对之前的参数进行多次调整，进而需要把之前的所有步骤重新测试一遍。

另外调优一般是从满足程序的内存使用需求开始的，之后是时间延迟的要求，最后才是吞吐量的要求，要基于这个步骤来不断优化，每一个步骤都是进行下一步的基础，不可逆行之。以下我们针对每个步骤进行详细的示例讲解。

在JVM的运行模式方面，我们直接选择server模式，这也是jdk1.6以后官方推荐的模式。

在垃圾收集器方面，我们直接采用了jdk1.6-1.8中默认的parallel收集器（新生代采用parallelGC，老生代采用parallelOldGC）。

三、确定内存占用

在确定内存占用之前，我们需要知道两个知识点：

应用程序的运行阶段

JVM内存分配

1、运行阶段

应用程序的运行阶段，我可以划分为以下三个阶段:

1、初始化阶段 : JVM加载应用程序，初始化应用程序的主要模块和数据。

2、稳定阶段:应用在此时运行了大多数时间，经历过压力测试的之后，各项性能参数呈稳定状态。核心函数被执行，已经被JIT编译预热过。

3、总结阶段:最后的总结阶段，进行一些基准测试，生成响应的策报告。这个阶段我们可以不关注。

确定内存占用以及活跃数据的大小，我们应该是在程序的稳定阶段来进行确定，而不是在项目起初阶段来进行确定，如何确定，我们先看以下JVM的内存分配。

2、`JVM`内存分配&参数

JVM堆中主要的空间，就是以上新生代、老生代、永久代组成，整个堆大小=新生代大小 + 老生代大小 + 永久代大小。具体的对象提升方式，这里不再过多介绍了，我们看下一些JVM命令参数，对堆大小的指定。如果不采用以下参数进行指定的话，虚拟机会自动选择合适的值，同时也会基于系统的开销自动调整。

分代	参数	描述
堆大小	-Xms	初始堆大小，默认为物理内存的`1/64(<1GB)`
	-Xmx	最大堆大小，默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制
新生代	-XX:NewSize	新生代空间大小初始值
	-XX:MaxNewSize	新生代空间大小最大值
	-Xmn	新生代空间大小，此处的大小是(eden+2 survivor space)
永久代	-XX:PermSize	永久代空间的初始值&最小值
	-XX：MaxPermSize	永久代空间的最大值
老年代	老年代的空间大小会根据新生代的大小隐式设定
	初始值=-Xmx减去-XX:NewSize的值
	最小值=-Xmx值减去-XX:MaxNewSize的值

在设置的时候，如果关注性能开销的话，应尽量把永久代的初始值与最大值设置为同一值，因为永久代的大小调整需要进行Full GC才能实现。

3、计算活跃数据大小

计算活跃数据大小应该遵循以下流程:

如前所述，活跃数据应该是基于应用程序稳定阶段时，观察长期存活与对象在java堆中占用的空间大小。

计算活跃数据时应该确保以下条件发生：

1.测试时，启动参数采用JVM默认参数，不人为设置。

2.确保Full GC发生时，应用程序正处于稳定阶段。

采用JVM默认参数启动，是为了观察应用程序在稳定阶段的所需要的内存使用。

如何才算稳定阶段？

一定得需要产生足够的压力，找到应用程序和生产环境高峰符合状态类似的负荷，在此之后达到峰值之后，保持一个稳定的状态，才算是一个稳定阶段。所以要达到稳定阶段，压力测试是必不可少的

在确定了应用出于稳定阶段的时候，要注意观察应用的GC日志，特别是Full GC日志。

GC日志指令: -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:<filename>

GC日志是收集调优所需信息的最好途径，即便是在生产环境，也可以开启GC日志来定位问题，开启GC日志对性能的影响极小，却可以提供丰富数据。

必须得有Full GC日志，如果没有的话，可以采用监控工具强制调用一次，或者采用以下命令，亦可以触发

1	jmap -histo:live pid

在稳定阶段触发了Full GC我们一般会拿到如下信息:

从以上GC日志中，我们大概可以分析到，在发生Full GC之时，整个应用的堆占用以及GC时间，当然了，为了更加精确，应该多收集几次，获取一个平均值。或者是采用耗时最长的一次Full GC来进行估算。

在上图中，Full GC之后，老年代空间占用在93168kb（约93MB），我们以此定为老年代空间的活跃数据。

其他堆空间的分配，基于以下规则来进行。

空间	命令参数	建议扩大倍数
`java heap`	`-Xms`和`-Xmx`	3-4倍`Full GC`后的老年代空间占用
永久代	`-XX:PermSize`和`-XX:MaxPermSize`	1.2-1.5倍`Full GC`后的永久带空间占用
新生代	`-Xmn`	1-1.5倍`Full GC`之后的老年代空间占用
老年代		2-3倍`Full GC`后的老年代空间占用

基于以上规则和上图中的Full GC信息，我们现在可以规划的该应用堆空间为：

java堆空间: 373Mb (=老年代空间93168kb*4)

新生代空间:140Mb(=老年代空间93168kb*1.5)

永久代空间:5Mb(=永久代空间3135kb*1.5)

老年代空间: 233Mb=堆空间-新生代看空间=373Mb-140Mb

对应的应用启动参数应该为:

java -Xms373m -Xmx373m -Xmn140m -XX:PermSize=5m -XX:MaxPermSize=5m

四、延迟调优

在确定了应用程序的活跃数据大小之后，我们需要再进行延迟性调优，因为对于此时堆内存大小，延迟性需求无法达到应用的需要，需要基于应用的情况来进行调试。

在这一步进行期间，我们可能会再次优化堆大小的配置，评估GC的持续时间和频率、以及是否需要切换到不同的垃圾收集器上。

1、系统延迟需求

在调优之前，我们需要知道系统的延迟需求是那些，以及对应的延迟可调优指标是那些。

应用程序可接受的平均停滞时间：此时间与测量的Minor GC持续时间进行比较。

可接受的Minor GC频率：Minor GC的频率与可容忍的值进行比较。

可接受的最大停顿时间：最大停顿时间与最差情况下Full GC的持续时间进行比较。

可接受的最大停顿发生的频率：基本就是Full GC的频率。

以上中，平均停滞时间和最大停顿时间，对用户体验最为重要，可以多关注。

基于以上的要求，我们需要统计以下数据:

Minor GC的持续时间；

统计Minor GC的次数；

Full GC的最差持续时间；

最差情况下，Full GC的频率；

2、优化新生代的大小

比如如上的GC日志中，我们可以看到Minor GC的平均持续时间=0.069秒，MinorGC的频率为0.389秒一次。

如果，我们系统的设置的平均停滞时间为50ms，当前的69ms明显是太长了，就需要调整。

我们知道新生代空间越大，Minor GC的GC时间越长，频率越低。

如果想减少其持续时长，就需要减少其空间大小。

如果想减小其频率，就需要加大其空间大小。

为了降低改变新生代的大小对其他区域的最小影响。在改变新生代空间大小的时候，尽量保持老年代空间的大小。

比如此次减少了新生代空间10%的大小，应该保持老年代和持代的大小不变化，第一步调优后的参数如下变化:

java -Xms359m -Xmx359m -Xmn126m -XX:PermSize=5m -XX:MaxPermSize=5m

新生代的大小有140m变为126m，堆大小顺应变化，此时老年代是没有变化的。

3、优化老年代的大小

同上一步一样，在优化之前，也需要采集gc日志的数据。此次我们关注的是FullGC的持续时间和频率。

上图中，我们可以看到
Full GC平均频率=5.8s，Full GC平均持续时间=0.14s

(以上为了测试，真实项目的Full GC没有这么快)

如果没有Full GC的日志，有办法可以评估么？

我们可以通过对象提升率进行计算。

对象提升率

比如上述中启动参数中，我们的老年代大小=233Mb。

那么需要多久才能填满老年代中这233Mb的空闲空间取决于新生代到老年代的提升率。

每次提升老年代占用量=每次Minor GC之后java堆占用情况减去 Minor GC后新生代的空间占用

对象提升率=平均值（每次提升老年代占用量) 除以老年代空间

有了对象提升率，我们就可以算出填充满老年代空间需要多少次Minor GC，大概一次Full GC的时间就可以计算出来了。

比如:

上图中:

第一次minor GC 之后，老年代空间:13740kb - 13732kb = 8kb

第二次minor GC 之后，老年代空间:22394kb - 17905kb = 4489kb

第三次minor GC 之后，老年代空间:34739kb - 17917kb = 16822kb

第四次minor GC 之后，老年代空间:48143kb - 17913kb = 30230kb

第五次minor GC 之后，老年代空间:62112kb - 17917kb = 44195kb

老年代每次minorGC提升率

4481kb 第2次和第`次minorGC之间

12333kb 第3次和第2次minorGC之间

13408kb 第4次和第3次minorGC之间

13965kb 第5次和第4次minorGC之间

我们可以测算出：

每次`Minor GC`的平均提升为`12211kb`，约为`12Mb`

上图中，平均`Minor GC`的频率为`213ms/次`

提升率=12211kb/213ms=57kb/ms

老年代空间233Mb ,占满大概需要233*1024/57=4185ms 约为4.185s。

Full GC的预期最差频率时长可以通过以上两种方式估算出来，可以调整老年代的大小来调整Full GC的频率，当然了，如果Full GC持续时间过长，无法达到应用程序的最差延迟要求，就需要切换垃圾处理器了。具体如何切换，下篇再讲，比如切换为CMS，针对CMS的调优方式又有会细微的差别。

五、吞吐量调优

经过上述漫长调优过程，最终来到了调优的最后一步，这一步对上述的结果进行吞吐量测试，并进行微调。

吞吐量调优主要是基于应用程序的吞吐量要求而来的，应用程序应该有一个综合的吞吐指标，这个指标基于真个应用的需求和测试而衍生出来的。当有应用程序的吞吐量达到或者超过预期的吞吐目标，整个调优过程就可以圆满结束了。

如果出现调优后依然无法达到应用程序的吞吐目标，需要重新回顾吞吐要求，评估当前吞吐量和目标差距是否巨大，如果在20%左右，可以修改参数，加大内存，再次从头调试，如果巨大就需要从整个应用层面来考虑，设计以及目标是否一致了，重新评估吞吐目标。

对于垃圾收集器来说，提升吞吐量的性能调优的目标就是就是尽可能避免或者很少发生FullGC或者Stop-The-World压缩式垃圾收集（CMS），因为这两种方式都会造成应用程序吞吐降低。尽量在Mino rGC阶段回收更多的对象，避免对象提升过快到老年代。

六、最后

据Plumbr公司对特定垃圾收集器使用情况进行了一次调查研究，研究数据使用了84936个案例。在明确指定垃圾收集器的13%的案例中，并发收集器（CMS）使用次数最多；但大多数案例没有选择最佳垃圾收集器。这个比例占用在87%左右。

JVM调优是一个系统而又复杂的工作，目前JVM下的自动调整已经做的比较优秀，基本的一些初始参数都可以保证一般的应用跑的比较稳定了，对部分团队来说，程序性能可能优先级不高，默认垃圾收集器已经够用了。调优要基于自己的情况而来。

原文作者：文／wier
原文标题：如何合理的规划一次jvm性能调优

posted @ 2019-07-31 15:51 qxwang 阅读(113) 评论(0) 收藏举报

刷新页面返回顶部

qxwang

JVM专题：JVM调优 优化篇

前言