iis配网站,温州市网站建设哪家公司好,网络营销有什么用,莱州网页设计公司转载自 如何合理的规划一次 JVM 性能调优摘要: JVM性能调优涉及到方方面面的取舍#xff0c;往往是牵一发而动全身,需要全盘考虑各方面的影响#xff0c;那么如何进行一次优雅的调优#xff0c;提升应用的性能#xff1f;这是 JVM 优化系列第三篇#xff1a;JVM 调优系列…转载自 如何合理的规划一次 JVM 性能调优摘要: JVM性能调优涉及到方方面面的取舍往往是牵一发而动全身,需要全盘考虑各方面的影响那么如何进行一次优雅的调优提升应用的性能这是 JVM 优化系列第三篇JVM 调优系列之监控工具JVM 调优系列之图解垃圾回收JVM性能调优涉及到方方面面的取舍往往是牵一发而动全身需要全盘考虑各方面的影响。但也有一些基础的理论和原则理解这些理论并遵循这些原则会让你的性能调优任务将会更加轻松。为了更好的理解本篇所介绍的内容。你需要已经了解和遵循以下内容:1、已了解jvm 垃圾收集器2、已了解jvm 性能监控常用工具3、能够读懂gc日志4、确信不为了调优而调优jvm调优不能解决一切性能问题这些内容在之前的两篇文章已经介绍过了如果有不了解的可以去点击上述连接进行回顾如果对这些不了解不建议读本篇文章。本篇文章基于jvm性能调优结合jvm的各项参数对应用程序调优主要内容有以下几个方面1、jvm调优的一般流程2、jvm调优所要关注的几个性能指标3、jvm调优需要掌握的一些原则4、调优策略示例性能调优的层次为了提升系统性能我们需要对系统的各个角度和层次来进行优化以下是需要优化的几个层次。从上面我们可以看到除了jvm调优以外还有其他几个层面需要来处理所以针对系统的调优不是只有jvm调优一项而是需要针对系统来整体调优才能提升系统的性能。本篇只针对jvm调优来讲解其他几个方面后续再介绍。在进行jvm调优之前我们假设项目的架构调优和代码调优已经进行过或者是针对当前项目是最优的。这两个是jvm调优的基础并且架构调优是对系统影响最大的 我们不能指望一个系统架构有缺陷或者代码层次优化没有穷尽的应用通过jvm调优令其达到一个质的飞跃这是不可能的。另外在调优之前必须得有明确的性能优化目标 然后找到其性能瓶颈。之后针对瓶颈的优化还需要对应用进行压力和基准测试通过各种监控和统计工具确认调优后的应用是否已经达到相关目标。JVM 调优流程调优的最终目的都是为了令应用程序使用最小的硬件消耗来承载更大的吞吐。jvm的调优也不例外jvm调优主要是针对垃圾收集器的收集性能优化令运行在虚拟机上的应用能够使用更少的内存以及延迟获取更大的吞吐量。当然这里的最少是最优的选择而不是越少越好。性能定义要查找和评估器性能瓶颈首先要知道性能定义对于jvm调优来说我们需要知道以下三个定义属性依作为评估基础:吞吐量重要指标之一是指不考虑垃圾收集引起的停顿时间或内存消耗垃圾收集器能支撑应用达到的最高性能指标。延迟其度量标准是缩短由于垃圾啊收集引起的停顿时间或者完全消除因垃圾收集所引起的停顿避免应用运行时发生抖动。内存占用垃圾收集器流畅运行所需要 的内存数量。这三个属性中其中一个任何一个属性性能的提高几乎都是以另外一个或者两个属性性能的损失作代价不可兼得具体某一个属性或者两个属性的性能对应用来说比较重要要基于应用的业务需求来确定。性能调优原则在调优过程中我们应该谨记以下3个原则以便帮助我们更轻松的完成垃圾收集的调优从而达到应用程序的性能要求。1. MinorGC回收原则 每次minor GC 都要尽可能多的收集垃圾对象。以减少应用程序发生Full GC的频率。2. GC内存最大化原则处理吞吐量和延迟问题时候垃圾处理器能使用的内存越大垃圾收集的效果越好应用程序也会越来越流畅。3. GC调优3选2原则: 在性能属性里面吞吐量、延迟、内存占用我们只能选择其中两个进行调优不可三者兼得。性能调优流程以上就是对应用程序进行jvm调优的基本流程我们可以看到jvm调优是根据性能测试结果不断优化配置而多次迭代的过程。在达到每一个系统需求指标之前之前的每个步骤都有可能经历多次迭代。有时候为了达到某一方面的指标有可能需要对之前的参数进行多次调整进而需要把之前的所有步骤重新测试一遍。另外调优一般是从满足程序的内存使用需求开始的之后是时间延迟的要求最后才是吞吐量的要求要基于这个步骤来不断优化每一个步骤都是进行下一步的基础不可逆行之。以下我们针对每个步骤进行详细的示例讲解。在JVM的运行模式方面我们直接选择server模式这也是jdk1.6以后官方推荐的模式。在垃圾收集器方面我们直接采用了jdk1.6-1.8 中默认的parallel收集器新生代采用parallelGC,老生代采用parallelOldGC。确定内存占用在确定内存占用之前我们需要知道两个知识点应用程序的运行阶段jvm内存分配运行阶段应用程序的运行阶段我可以划分为以下三个阶段:1、初始化阶段 : jvm加载应用程序初始化应用程序的主要模块和数据。2、稳定阶段:应用在此时运行了大多数时间经历过压力测试的之后各项性能参数呈稳定状态。核心函数被执行已经被jit编译预热过。3、总结阶段:最后的总结阶段进行一些基准测试生成响应的策报告。这个阶段我们可以不关注。确定内存占用以及活跃数据的大小我们应该是在程序的稳定阶段来进行确定而不是在项目起初阶段来进行确定如何确定我们先看以下jvm的内存分配。JVM 内存分配参数jvm堆中主要的空间就是以上新生代、老生代、永久代组成,整个堆大小新生代大小 老生代大小 永久代大小。 具体的对象提升方式这里不再过多介绍了我们看下一些jvm命令参数对堆大小的指定。如果不采用以下参数进行指定的话虚拟机会自动选择合适的值同时也会基于系统的开销自动调整。在设置的时候如果关注性能开销的话应尽量把永久代的初始值与最大值设置为同一值因为永久代的大小调整需要进行FullGC 才能实现。计算活跃数据大小计算活跃数据大小应该遵循以下流程:如前所述活跃数据应该是基于应用程序稳定阶段时观察长期存活与对象在java堆中占用的空间大小。计算活跃数据时应该确保以下条件发生1.测试时启动参数采用jvm默认参数不人为设置。2.确保Full GC 发生时应用程序正处于稳定阶段。采用jvm默认参数启动是为了观察应用程序在稳定阶段的所需要的内存使用。如何才算稳定阶段一定得需要产生足够的压力找到应用程序和生产环境高峰符合状态类似的负荷在此之后达到峰值之后保持一个稳定的状态才算是一个稳定阶段。所以要达到稳定阶段压力测试是必不可少的具体如何如何对应用压力测试本篇不过多说明,后期会有专门介绍的篇幅。在确定了应用出于稳定阶段的时候要注意观察应用的GC日志特别是Full GC 日志。GC日志指令: -XX:PrintGCTimeStamps -XX:PrintGCDetails -Xloggc:filenameGC日志是收集调优所需信息的最好途径即便是在生产环境也可以开启GC日志来定位问题开启GC日志对性能的影响极小却可以提供丰富数据。必须得有FullGC 日志如果没有的话可以采用监控工具强制调用一次或者采用以下命令亦可以触发jmap -histo:live pid在稳定阶段触发了FullGC我们一般会拿到如下信息:从以上gc日志中我们大概可以分析到在发生fullGC之时整个应用的堆占用以及GC时间当然了为了更加精确应该多收集几次获取一个平均值。或者是采用耗时最长的一次FullGC来进行估算。在上图中fullGC之后老年代空间占用在93168kb约93MB我们以此定为老年代空间的活跃数据。其他堆空间的分配基于以下规则来进行。基于以上规则和上图中的FullGC信息我们现在可以规划的该应用堆空间为java 堆空间: 373Mb (老年代空间93168kb*4)新生代空间:140Mb(老年代空间93168kb*1.5)永久代空间:5Mb(永久代空间3135kb*1.5)老年代空间: 233Mb堆空间-新生代看空间373Mb-140Mb对应的应用启动参数应该为:延迟调优在确定了应用程序的活跃数据大小之后我们需要再进行延迟性调优因为对于此时堆内存大小延迟性需求无法达到应用的需要需要基于应用的情况来进行调试。在这一步进行期间我们可能会再次优化堆大小的配置评估GC的持续时间和频率、以及是否需要切换到不同的垃圾收集器上。系统延迟需求在调优之前我们需要知道系统的延迟需求是那些以及对应的延迟可调优指标是那些。应用程序可接受的平均停滞时间: 此时间与测量的Minor GC持续时间进行比较。可接受的Minor GC频率Minor GC的频率与可容忍的值进行比较。可接受的最大停顿时间: 最大停顿时间与最差情况下FullGC的持续时间进行比较。可接受的最大停顿发生的频率基本就是FullGC的频率。以上中平均停滞时间和最大停顿时间对用户体验最为重要可以多关注。基于以上的要求我们需要统计以下数据:MinorGC的持续时间统计MinorGC的次数FullGC的最差持续时间最差情况下FullGC的频率优化新生代的大小比如如上的gc日志中我们可以看到Minor GC的平均持续时间0.069秒MinorGC 的频率为0.389秒一次。如果我们系统的设置的平均停滞时间为50ms当前的69ms明显是太长了就需要调整。我们知道新生代空间越大Minor GC的GC时间越长频率越低。如果想减少其持续时长就需要减少其空间大小。如果想减小其频率就需要加大其空间大小。为了降低改变新生代的大小对其他区域的最小影响。在改变新生代空间大小的时候尽量保持老年代空间的大小。比如此次减少了新生代空间10%的大小应该保持老年代和持代的大小不变化第一步调优后的参数如下变化:优化老年代的大小同上一步一样在优化之前也需要采集gc日志的数据。此次我们关注的是FullGC的持续时间和频率。上图中我们可以看到如果没有FullGC的日志有办法可以评估么我们可以通过对象提升率进行计算。对象提升率比如上述中启动参数中我们的老年代大小233Mb。那么需要多久才能填满老年代中这233Mb的空闲空间取决于新生代到老年代的提升率。每次提升老年代占用量每次MinorGC 之后 java堆占用情况 减去 MinorGC后新生代的空间占用对象提升率平均值每次提升老年代占用量) 除以 老年代空间有了对象提升率我们就可以算出填充满老年代空间需要多少次minorGC大概一次fullGC的时间就可以计算出来了。比如:上图中:老年代每次minorGC提升率我们可以测算出FullGC的预期最差频率时长可以通过以上两种方式估算出来可以调整老年代的大小来调整FullGC的频率当然了如果FullGC持续时间过长无法达到应用程序的最差延迟要求就需要切换垃圾处理器了。具体如何切换下篇再讲比如切换为CMS针对CMS的调优方式又有会细微的差别。吞吐量调优经过上述漫长 调优过程最终来到了调优的最后一步这一步对上述的结果进行吞吐量测试并进行微调。吞吐量调优主要是基于应用程序的吞吐量要求而来的应用程序应该有一个综合的吞吐指标这个指标基于真个应用的需求和测试而衍生出来的。当有应用程序的吞吐量达到或者超过预期的吞吐目标整个调优过程就可以圆满结束了。如果出现调优后依然无法达到应用程序的吞吐目标需要重新回顾吞吐要求评估当前吞吐量和目标差距是否巨大如果在20%左右可以修改参数加大内存再次从头调试如果巨大就需要从整个应用层面来考虑设计以及目标是否一致了重新评估吞吐目标。对于垃圾收集器来说提升吞吐量的性能调优的目标就是就是尽可能避免或者很少发生FullGC 或者Stop-The-World压缩式垃圾收集CMS因为这两种方式都会造成应用程序吞吐降低。尽量在MinorGC 阶段回收更多的对象避免对象提升过快到老年代。最后据Plumbr公司对特定垃圾收集器使用情况进行了一次调查研究研究数据使用了84936个案例。在明确指定垃圾收集器的13%的案例中并发收集器CMS使用次数最多但大多数案例没有选择最佳垃圾收集器。这个比例占用在87%左右。JVM调优是一个系统而又复杂的工作目前jvm下的自动调整已经做的比较优秀基本的一些初始参数都可以保证一般的应用跑的比较稳定了对部分团队来说程序性能可能优先级不高默认垃圾收集器已经够用了。调优要基于自己的情况而来。
