`
ganlv
  • 浏览: 34928 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论

一步步优化JVM五:优化延迟或者响应时间(3)

阅读更多

CMS垃圾回收器周期   


   一旦young的空间大小(包含eden和survivor空间)已经完善得满足应用对MinorGC产生延迟要求,注意力可以转移到优化CMS垃圾回收器,降低最差延迟时间的时间长度以及最小化最差延迟的频率。目标是保持可用的old代空间和并发垃圾回收,避免stop-the-world压缩垃圾回收。

   stop-the-world压缩垃圾回收是垃圾回收影响延迟的最差情况,对某些应用来说,恐怕无法完全避免开这些,但是本节提供的优化信息至少可以减少他们的频率。

   成功的优化CMS垃圾回收器需要达到的效果是old代的里面的垃圾回收的效率要和young代转移对象到old代的效率相同,没有能够完成这个标准可以称为“比赛失败”,比赛失败的结果就是导致stop-the-world压缩垃圾回收。不比赛中失败的一个关键是让下面两个事情结合起来:1、old代有足够的空间。2、启动CMS垃圾回收周期开始时机——快到回收对象的速度比较转移对象来的速度更快。

   CMS周期的启动是基于old代的空间大小的。如果CMS周期开始的太晚,他就会输掉比赛,没有能够快速的回收对象以避免溢出old代空间。如果CMS周期开始得太早,会造成不必要的压力以及影响应用的吞吐量。但是,通常来讲过早的启动总比过晚的启动好。

   HotSpot VM自动地计算出当占用是多少时启动CMS垃圾回收周期。不过在一些场景下,对于避免stop-the-world垃圾回收,他做得并不好。如果观察到stop-the-world垃圾回收,你可以优化该什么时候启动CMS周期。在CMS垃圾回收中,stop-the-world压缩垃圾回收在垃圾回收日志中输出是“concurrent mode failure”,下面一个例子:

   174.445: [GC 174.446: [ParNew: 66408K->66408K(66416K), 0.0000618
   secs]174.446: [CMS ( concurrent mode failure): 161928K->162118K(175104K),
   4.0975124 secs] 228336K->162118K(241520K)

   如果你发现有concurrent mode failure你可以通过下面这个选项来控制什么时候启动CMS垃圾回收:

   
-XX:CMSInitiatingOccupancyFraction=<percent>


   这个值指定了CMS垃圾回收时old代的空间占用率该是什么值。举例说明,如果你希望old代占用率是65%的时候,启动CMS垃圾回收,你可以设置-XX:CMSInitiatingOccupancyFraction=65。另外一个可以同时使用的选项是

   
-XX:+UseCMSInitiatingOccupancyOnly


   -XX:+UseCMSInitiatingOccupancyOnly指定HotSpot VM总是使用-XX:CMSInitiatingOccupancyFraction的值作为old的空间使用率限制来启动CMS垃圾回收。如果没有使用-XX:+UseCMSInitiatingOccupancyOnly,那么HotSpot VM只是利用这个值来启动第一次CMS垃圾回收,后面都是使用HotSpot VM自动计算出来的值。

   -XX:CMSInitiatingOccupancyFraction=<percent>这个指定的值,应该比垃圾回收之后存活对象的占用率更高,怎么样计算存活对象的大小前面在“决定内存占用”的章节已经说过了。如果<percent>不比存活对象的占用量大,CMS垃圾回收器会一直运行。通常的建议是-XX:CMSInitiatingOccupancyFraction的值应该是存活对象的占用率的1.5倍。举例说明一下,假如用下面的Java堆选项配置:

   
-Xmx1536m -Xms1536m -Xmn512m


   那么old代的空间大小是1024M(1536-512 = 1024m)。如果存活对象的大小是350M的话,CMS垃圾回收周期的启动阀值应该是old代占用空间是525M,那么占用率就应该是51%(525/1024=51%),这个只是初始值,后面还可能根据垃圾回收日志进行修改。那么修改后的命令行选项是:

   
-Xmx1536m -Xms1536m -Xmn512m  -XX:+UseCMSInitiatingOccupancyOnly 
   -XX:CMSInitiatingOccupancyFraction=51


   该多早或者多迟启动CMS周期依赖于对象从young代转移到old代的速率,也就是说,old代空间的增长率。如果old代填充速度比较缓慢,你可以晚一些启动CMS周期,如果填充速度很快,那么就需要早一点启动CMS周期,但是不能小于存活对象的占用率。如果需要设置得比存活对象的占用率小,应该是增加old代的空间。

   想知道CMS周期是开始的太早还是太晚,可以通过评估垃圾回收信息识别出来。下面是一个CMS周期开始得太晚的例子。为了更好阅读,稍微修改了输出内容:

[ParNew 742993K->648506K(773376K), 0.1688876 secs]
[ParNew 753466K->659042K(773376K), 0.1695921 secs]
[CMS-initial-mark 661142K(773376K), 0.0861029 secs]
[Full GC 645986K->234335K(655360K), 8.9112629 secs]
[ParNew 339295K->247490K(773376K), 0.0230993 secs]
[ParNew 352450K->259959K(773376K), 0.1933945 secs]

   注意FullGC在CMS-inital-mark之后很快就发生了。CMS-initial-mark是报告CMS周期多个字段中的一个。下面的例子会使用到更多的字段。

    下面是一个CMS开始的太早了的情况:
 
[ParNew 390868K->296358K(773376K), 0.1882258 secs]
[CMS-initial-mark 298458K(773376K), 0.0847541 secs]
[ParNew 401318K->306863K(773376K), 0.1933159 secs]
[CMS-concurrent-mark: 0.787/0.981 secs]
[CMS-concurrent-preclean: 0.149/0.152 secs]
[CMS-concurrent-abortable-preclean: 0.105/0.183 secs]
[CMS-remark 374049K(773376K), 0.0353394 secs]
[ParNew 407285K->312829K(773376K), 0.1969370 secs]
[ParNew 405554K->311100K(773376K), 0.1922082 secs]
[ParNew 404913K->310361K(773376K), 0.1909849 secs]
[ParNew 406005K->311878K(773376K), 0.2012884 secs]
[CMS-concurrent-sweep: 2.179/2.963 secs]
[CMS-concurrent-reset: 0.010/0.010 secs]
[ParNew 387767K->292925K(773376K), 0.1843175 secs]
[CMS-initial-mark 295026K(773376K), 0.0865858 secs]
[ParNew 397885K->303822K(773376K), 0.1995878 secs]

   CMS-initial-mark表示CMS周期的开始, CMS-initial-sweepCMS-concurrent-reset表示周期的结束。注意第一个CMS-initial-mark报告堆大小是298458K,然后注意,ParNew MinorGC报告在CMS-initial-mark和CMS-concurrent-reset之间只有很少的占用量变化,堆的占用量可以通过ParNew的->的右边的数值来表示。在这个例子中,CMS周期回收了很少的垃圾,通过在CMS-initial-mark和CMS-concurrent-reset之间只有很少的占用量变化可看出来。这里正确的做法是启动CMS周期用更大的old代空间占用率,通过使用参数
-XX:+UseCMSInitiatingOccupancyOnly和-XX:CMSInitiatingOccupancyFraction=<percent>。基于初始CMS-initial-mark占用量是298458K以及Java堆的大小是773376K,就是CMS发生的占用率是35%到40%(298458K/773376K=38.5%),可以使用选项来强制提高占用率的值。

   下面是一个CMS周期回收了大量old代空间的例子,而且没有经历stop-the-world压缩垃圾回收,也就没有并发错误(concurrent mode failure)。同样的修改输出格式:

[ParNew 640710K->546360K(773376K), 0.1839508 secs]
[CMS-initial-mark 548460K(773376K), 0.0883685 secs]
[ParNew 651320K->556690K(773376K), 0.2052309 secs]
[CMS-concurrent-mark: 0.832/1.038 secs]
[CMS-concurrent-preclean: 0.146/0.151 secs]
[CMS-concurrent-abortable-preclean: 0.181/0.181 secs]
[CMS-remark 623877K(773376K), 0.0328863 secs]
[ParNew 655656K->561336K(773376K), 0.2088224 secs]
[ParNew 648882K->554390K(773376K), 0.2053158 secs]
[ParNew 489586K->395012K(773376K), 0.2050494 secs]
[ParNew 463096K->368901K(773376K), 0.2137257 secs]
[CMS-concurrent-sweep: 4.873/6.745 secs]
[CMS-concurrent-reset: 0.010/0.010 secs]
[ParNew 445124K->350518K(773376K), 0.1800791 secs]
[ParNew 455478K->361141K(773376K), 0.1849950 secs]

   在这个例子中,在CMS周期开始的时候,CMS-initial-mark表明占用量是548460K。在CMS周期开始和结束(CMS-concurrent-reset)之间,ParNew MinorGC报告显著的减少了对象的占用量。尤其,在CMS-concurrent-sweep之前,占用量从561336K降低到了368901K。这个表明在CMS周期中,有190M空间被垃圾回收。需要注意的是,在CMS-concurrent-sweep之后的第一个ParNew MinorGC报告的占用量是350518K。这个说明超过190M被垃圾回收(561336K-350518K=210818K=205.88M)。

   如果你决定优化CMS周期的启动,多尝试几个不同的old代占用率。监控垃圾回收信息以及分析这些信息可以帮助你做出正确的决定。

强制的垃圾回收
   如果你想要观察通过调用System.gc()来启动的FullGC,当使用用CMS的时候,有两种方法来处理这种情况。

   1、你可以请求HotSpot VM执行System.gc()的时候使用CMS周期,使用如下命令选项:

 
 -XX:+ExplicitGCInvokesConcurrent
   或者
   -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses


   第一个选项在Java 6及更新版本中能够使用,第二选项在从Java 6 Update 4之后才有。如果可以,建议使用后者。

   2、你可以请求HotSpot VM选项忽视强制的调用System.gc(),可以使用如下选项:

   
-XX:+DisableExplicitGC



   这个选项用来让其他垃圾回收器忽略System.gc()请求。
   
   当关闭的强制垃圾回收需要小心,这样做可能对Java性能产生很大的影响,关闭这个功能就像使用System.gc()一样需要明确的理由。

   在垃圾回收日志里面找出明确的垃圾回收信息是非常容易的。垃圾回收的输出里面包含了一段文字来说明FullGC是用于调用System.gc().下面是一个例子:

2010-12-16T23:04:39.452-0600: [Full GC (System)
[CMS: 418061K->428608K(16384K), 0.2539726 secs]
418749K->4288608K(31168K),
[CMS Perm : 32428K->32428K(65536K)],0.2540393 secs]
[Times: user=0.12 sys=0.01, real=0.25 secs]

   注意Full GC后面的(System)标签,这个说明是System.gc()引起的FullGC。如果你在垃圾回收日志里面观察到了明确的FullGC,想想为什么会出现、是否需要关闭、是否需要把应用源代码里面的相关代码删除掉,对CMS垃圾回收周期是否有意义。

并发的Permanent代垃圾回收

    FullGC发生可能是由于permanent空间满了引起的,监控FullGC垃圾回收信息,然后观察Permanent代的占用量,判断FullGC是否是由于permanent区域满了引起的。下面是一个由于permanent代满了引起的FullGC的例子:

2010-12-16T17:14:32.533-0600: [Full GC
[CMS: 95401K->287072K(1048576K), 0.5317934 secs]
482111K->287072K(5190464K),
[CMS Perm : 65534K->58281K(65536K)], 0.5319635 secs]
[Times: user=0.53 sys=0.00, real=0.53 secs]

    注意permanent代的空间占用量,通过CMS Perm :标签识别。permanent代空间大小是括号里面的值,65536K。在FullGC之前permanent代的占用量是->左边的值,65534K,FullGC之后的值是58281K。可以看到的是,在FullGC之前,permanent代的占用量以及基本上和permanent代的容量非常接近了,这个说明,FullGC是由Permanent代空间溢出导致的。同样需要注意的是,old代还没有到溢出空间的时候,而且没有证据说明CMS周期启动了。

   HotSpot VM默认情况下,CMS不会垃圾回收permanent代空间,尽管垃圾回收日志里面有CMS Perm标签。为让CMS回收permanent代的空间,可以用过下面这个命令选项来做到:

   
-XX:+CMSClassUnloadingEnabled


   如果使用Java 6 update 3及之前的版本,你必须指定一个命令选项:

 
 -XX:+CMSPermGenSweepingEnabled


   你可以控制permanent的空间占用率来启动CMS permanent代垃圾回收通过下面这个命令选项:

   
-XX:CMSInitiatingPermOccupancyFraction=<percent>


   这个参数的功能和-XX:CMSInitiatingOccupancyFraction很像,他指的是启动CMS周期的permanent代的占用率。这个参数同样需要和-XX:+CMSClassUnloadingEnabled配合使用。如果你想一直使用-XX:CMSInitiatingPermOccupancyFraction的值作为启动CMS周期的条件,你必须要指定另外一个选项:

   
-XX:+UseCMSInitiatingOccupancyOnly


CMS暂停时间优化

   在CMS周期里面,有两个阶段是stop-the-world阶段,这个阶段所有的应用线程都被阻塞了。这两阶段是“初始标记”阶段和“再标记”阶段,尽管初始标记解决是单线程的,但是通过不需要花费太长时间,至少比其他垃圾回收的时间短。再标记阶段是多线程的,线程数可通过命令选项来控制:

   
-XX:ParallelGCThreads=<n>


   在Java 6 update 23之后,默认值是通过Runtime.availableProcessors()来确定的,不过是建立在返回值小于等于8的情况下,反之,会使用Runtime.availableProcessors()*5/8作为线程数。如果有多个程序运行在同一个机器上面,建议使用比默认线程数更少的线程数。否则,垃圾回收可能会引起其他应用的性能下降,由于在同一个时刻,垃圾回收器使用太多的线程。

   在某些情况下设置下面这个选项可以减少再标记的时间:

   
-XX:+CMSScavengeBeforeRemark


   这个选项强制HotSpot VM在FullGC之前执行MinorGC,在再标记步骤之前做MinorGC,可以减少再标记的工作量,由于减少了young代的对象数,这些对象能够在old代获取到的。

   如果应用有大量的引用或者finalizable对象需要处理,指定下面这个选项可以减少垃圾回收的时间:

   
-XX:+ParallelRefProcEnabled

   这个选项可以用HotSpot VM的任何一种垃圾回收器上,他会是用多个的引用处理线程,而不是单个线程。这个选项不会启用多线程运行方法的finalizer。他会使用很多线程去发现需要排队通知的finalizable对象。

下一步

   这一步结束,你需要看看应用的延迟需要是否满足了,无论是使用throughput垃圾回收器或者并发垃圾回收器。如果没有能够满足应用的需要,那么回头看看需求是否合理或者修改应用程序。如果满足了应用的需求,那么我们就进入下一步——优化吞吐量。

分享到:
评论

相关推荐

    一步步优化JVM.docx

    3. **响应时间**:用户请求到系统响应之间的时间,优化响应时间可以提升用户体验。 4. **内存占用**:优化内存使用可以减少系统资源消耗,但可能导致性能下降,需要找到平衡点。 5. **启动时间**:优化启动时间...

    WebSphere性能优化之二:JVM的运行效率.doc

    总的来说,WebSphere的JVM性能优化是一个复杂的过程,需要根据实际运行情况不断调整和测试。通过细致的监控和分析,结合适当的JVM参数设置,可以有效地提升WebSphere的运行效率,减少因内存管理问题引发的性能瓶颈。...

    jvm初识及JIT优化

    jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识...

    JVM面试资料:JVM结构、JVM调优、四大垃圾回收算法、七大垃圾回收器

    JVM面试资料。 JVM结构:类加载器,执行引擎,本地方法接口,本地内存结构; 四大垃圾回收算法:复制算法、标记-清除算法、标记-整理算法、分代收集算法 七大垃圾回收器:Serial、Serial Old、ParNew、CMS、Parallel...

    JVM内存模型深度剖析与优化.pdf

    JVM内存模型深度剖析与优化 JVM内存模型是Java虚拟机的核心组件之一,它直接影响着Java应用程序的性能和可靠性。本文将深入剖析JVM内存模型的结构和工作机理,并讨论如何优化JVM参数以提高Java应用程序的性能。 一...

    深入JVM内核—原理、诊断与优化

    《深入JVM内核—原理、诊断与优化》是一份深度探索Java虚拟机(JVM)的视频教程,旨在帮助开发者全面理解JVM的工作机制,掌握性能诊断技巧,并能进行有效的优化。本教程覆盖了从基础到高级的JVM主题,不仅适用于Java...

    淘宝JVM优化实践-长仁.pdf

    《淘宝JVM优化实践》是一份深入探讨阿里巴巴集团核心系统研发部在JVM优化方面的实践经验的文档。这份文档主要涵盖了以下几个关键知识点: 1. **淘宝JVM优化背景**:随着淘宝、天猫等业务的快速发展,其Java应用规模...

    jvm详细介绍以及性能优化方法

    优化Tomcat涉及多个方面,包括调整连接器配置(如最大连接数、超时时间)、线程池设置、Web应用的部署优化(如减少session使用、压缩响应内容)以及启用HTTP/2协议等。此外,监控Tomcat的运行状态,如CPU使用率、...

    jvm优化参数配置

    "jvm优化参数配置"是确保Tomcat稳定运行的关键环节,能够提高应用的响应速度,减少内存泄露,提升系统整体性能。以下是对JVM参数优化的详细解释: 1. **内存配置**: - **堆内存(Heap Memory)**:分为新生代...

    openjdk jvm zgc低延迟

    OpenJDK JVM 的 ZGC(Z Garbage Collector)是一个针对低延迟需求设计的垃圾收集器。这个GC的主要目标是提供可扩展的低延迟性能,即使在处理多TB大小的堆内存时也能保持极短的垃圾收集暂停时间。Oracle公司开发的ZGC...

    JVM详解:带书签超清文字版.pdf

    #### 一、Java与JVM概览 **1.1 Java定义** Java是一种广泛使用的面向对象的编程语言,以其强大的跨平台兼容性和安全性著称。Java程序能够运行在任何安装了Java运行环境(JRE)的设备上,这得益于Java虚拟机(JVM)...

    深入理解JVM内幕:从基本结构到Java 7新特性

    Java虚拟机(JVM)是Java程序的核心组件,它负责解析和执行Java字节码,使得Java具有“一次编译,到处运行”的特性。本文将深入探讨JVM的基本结构、执行流程,以及Java 7的新特性。 首先,JVM由Java API和JRE组成,...

    JVM性能优化(PPT)

    JVM性能优化是一项细致而关键的任务,能够显著提升程序的运行效率,减少资源消耗,提高系统稳定性。本PPT详细探讨了JVM的工作原理以及如何进行性能优化。 1. **JVM架构** JVM分为几个主要区域:方法区、堆、栈、...

    JVM性能优化:线程锁优化.docx

    Java虚拟机(JVM)性能优化的一个重要领域是线程锁优化,这直接影响到多线程应用程序的效率和并发性能。线程锁是确保多线程环境下数据一致性和线程安全的关键机制。以下是对线程锁优化的一些核心知识点的详细说明: ...

    JVM优化3(Tomcat参数调优,JVM参数调优,jvm字节码,代码优化).zip

    这个压缩包文件"JVM优化3(Tomcat参数调优,JVM参数调优,jvm字节码,代码优化).zip"显然包含了关于如何优化Java应用程序运行效率的四个主要方面:Tomcat服务器的参数调整、JVM参数调优、JVM字节码理解和优化以及代码...

    JVM系列之性能调优参考手册(实践篇).pdf

    标题《JVM系列之性能调优参考手册(实践篇)》涉及的知识点主要集中在Java虚拟机(JVM)性能调优的实践操作。JVM作为Java程序运行的基础环境,对程序性能有着决定性影响。本手册的目的是指导开发者如何对JVM进行性能...

    深入jvm 内核-原理,诊断于优化视频教程

    ### 深入JVM内核:原理、诊断与优化 #### 一、JVM基础知识 **1.1 JVM概念** Java虚拟机(Java Virtual Machine,简称JVM)是一种用于执行Java字节码的虚拟机。它为Java程序提供了一个运行环境,能够独立于硬件平台...

    深入JVM内核—原理、诊断与优化视频教程-3.常用JVM配置参数

    JVM主要由类加载子系统、运行时数据区、执行引擎、本地方法接口和本地方法库五个部分组成。其中,类加载子系统负责加载、验证、准备和初始化类文件;运行时数据区包括堆、栈、方法区、程序计数器和本地方法栈,它们...

Global site tag (gtag.js) - Google Analytics