芙蓉区乡建设局网站,商城网站建设案例,网站设置不能手机访问,建设网站的预期收益本文将向您详细介绍从Java虚拟机#xff08;例如HotSpot或JRockit#xff09;迁移到IBM JVM时重要的Java堆空间调整注意事项。 该调整建议基于我为我的一个IT客户端执行的最新故障排除和调整任务。 IBM JVM概述 正如您可能从其他文章中看到的那样#xff0c;IBM JVM在某些方… 本文将向您详细介绍从Java虚拟机例如HotSpot或JRockit迁移到IBM JVM时重要的Java堆空间调整注意事项。 该调整建议基于我为我的一个IT客户端执行的最新故障排除和调整任务。 IBM JVM概述 正如您可能从其他文章中看到的那样IBM JVM在某些方面与HotSpot JVM不同因为它没有PermGen内存空间。 从垃圾回收的角度来看它确实为您提供了可以利用多物理核心计算机的高级算法 与HotSpot JVM类似。 从故障诊断的角度来看IBM为您提供了许多工具。 包括从其JVM实现中获得的开箱即用的Thread Dump和Heap Dump生成功能。 例如IBM JVM线程转储特别强大因为它为您提供了有关JVM的额外数据例如活动的JVM环境变量GC策略每个活动的类加载器中的已加载类等。我们将在本部分中对此进行更详细的探讨。我们的线程转储培训计划的4 。 IBM VM –默认GC行为 现在回到我们的主要主题了解IBM JVM垃圾收集器版本1.5和1.6的默认行为非常重要。 默认情况下使用终身记忆只例如它不会创建一个单独的YoungGen幼儿园空间中创建了Java堆空间。 这意味着任何内存分配都将进入租用空间短期和长期对象该空间随后由默认收集器通过Full GC收集。 在下面找到详细的GC快照其中显示了默认的GC内存故障并带有解释 af typetenured id5 timestampMar 01 13:40:30 2012 intervalms0.000minimum requested_bytes48 /time exclusiveaccessms0.106 meanexclusiveaccessms0.106 threads0 lastthreadtid0x000000011A846B00 /tenured freebytes20131840 totalbytes2013265920 percent0 soa freebytes0 totalbytes1993134080 percent0 /loa freebytes20131840 totalbytes20131840 percent100 //tenuredgc typeglobal id8 totalid2492 intervalms2017588.587finalization objectsqueued199 /timesms mark808.286 sweep9.341 compact0.000 total818.292 /tenured freebytes1362331024 totalbytes2013265920 percent67 soa freebytes1344212368 totalbytes1995147264 percent67 /loa freebytes18118656 totalbytes18118656 percent100 //tenured/gctenured freebytes1362330976 totalbytes2013265920 percent67 soa freebytes1344212320 totalbytes1995147264 percent67 /loa freebytes18118656 totalbytes18118656 percent100 //tenuredtime totalms818.750 //af 好的默认的IBM JVM GC策略是不同的……问题是什么 此默认JVM策略的问题在于所有Java对象都被复制到租用空间并通过全局集合完整GC进行收集。 对于许多Java EE应用程序短期对象与长期对象的比率要高得多。 这意味着您的JVM将需要执行很多主要的收集工作以清理短期对象。 结果Full GC的频率增加JVM暂停时间增加CPU利用率增加和性能下降 这正是我们在使用默认GC策略将JVM HotSpot 1.5使用增量和并行GC迁移到IBM JVM 1.6之后执行负载测试时观察到的结果。 根据上述说明重度GC过程被确定为根本原因。 请解决 好消息是IBM JVM 从版本1.5开始引入了世代和并发GC收集器 。 该GC政策正是提供了我们想要的 它确实将Java Heap空间在苗圃空间和保育空间之间进行了划分 托儿所YoungGen空间对象通过清除剂GC收集器单独收集 通过全局GC收集器收集长期空间对象 GC收集器是并发的并且可以利用任何多物理核计算机 结果 降低主要采集频率全GC 减少了全GC消耗的时间和暂停时间 增加JVM吞吐量 提高应用程序的性能和容量 您可以通过在下面添加此JVM参数来启用它 -Xgcpolicy:gencon 在启用此GC策略后在下面的详细GC日志中可以找到什么 af typenursery id15 timestampMar 08 05:34:06 2012 intervalms1289096.227minimum requested_bytes40 /time exclusiveaccessms0.085 meanexclusiveaccessms0.085 threads0 lastthreadtid0x0000000118113900 /refs soft18043 weak204057 phantom27 dynamicSoftReferenceThreshold32 maxSoftReferenceThreshold32 /nursery freebytes0 totalbytes530716672 percent0 /tenured freebytes1887422016 totalbytes2013265920 percent93 soa freebytes1786758720 totalbytes1912602624 percent93 /loa freebytes100663296 totalbytes100663296 percent100 //tenuredgc typescavenger id15 totalid15 intervalms1289097.271flipped objectcount1486449 bytes129908000 /tenured objectcount1176 bytes184144 /finalization objectsqueued3082 /scavenger tiltratio73 /nursery freebytes364304408 totalbytes495208448 percent73 tenureage10 /tenured freebytes1886766656 totalbytes2013265920 percent93 soa freebytes1786103360 totalbytes1912602624 percent93 /loa freebytes100663296 totalbytes100663296 percent100 //tenuredtime totalms233.886 //gcnursery freebytes364238872 totalbytes495208448 percent73 /tenured freebytes1886766656 totalbytes2013265920 percent93 soa freebytes1786103360 totalbytes1912602624 percent93 /loa freebytes100663296 totalbytes100663296 percent100 //tenuredrefs soft17992 weak5344 phantom27 dynamicSoftReferenceThreshold32 maxSoftReferenceThreshold32 /time totalms236.858 //af 请记住您的应用程序仍可能无法从该GC策略中受益长寿命对象等会占用更大的空间因此我对您的建议是始终进行尽职调查并执行适当的容量规划和负载测试您的应用程序然后再执行任何主要的调整建议。 结论 我希望本文能帮助您了解默认的IBM JVM 1.5 / 1.6 GC策略以及Java EE应用程序如何从该GC策略gencon调整建议中受益。 参考 IBM JVM调优–来自我们JCG合作伙伴 Pierre-Hugues Charbonneau的gencon GC策略 位于Java EE支持模式和Java教程博客。 翻译自: https://www.javacodegeeks.com/2012/04/ibm-jvm-tuning-gencon-gc-policy.html
