WebSphere性能调优-垃圾收集器

最新推荐文章于 2020-12-09 22:58:57 发布
最新推荐文章于 2020-12-09 22:58:57 发布
阅读量1.1k 收藏
点赞数
分类专栏： 架构 文章标签： JVM 性能优化 应用
 
        基于WebSphere 构建的企业应用，时常会出现性能问题，在严重的情况下还会提示出内存溢出，这是一件很让人恼怒的事情。在WebSphere Application Server(Was)运行的时候，内存溢出，会生成大量的溢出文件，如Javacore, Heapdump等文件，占用了大量的磁盘空间。在这种情况下，时常会出现一连串的系统问题，如部署在Was的所有应用服务都报错，Was连控制台也无法访问等。

     为解决问题，我们通常会选择重新启动整个Was或者服务器，然后分析运行日志SystemOut.log、ystemErr.log、ative_stdout.log、native_stderr.log 和系统内存溢出的时候产生的Javacore、Heapdump文件来寻找出问题。

    那么，为什么会出现内存溢出呢？

    应用服务器在运行过程中需要创建很多对象，而在应用服务器的堆空间大小有限的情况下，请求进程不断申请空间来创建与存放对象，在达到上限时而服务器又没能释放出空间来处理申请空间的请求就会出现内存溢出情况。这就像吹气球，当气球中的气体到达一定程度时，气球就会被撑爆。（32位的JDK的Jvm堆空间分配最大支持1.5G的大小，超过则无法正常启动。而64位的JDK堆大小分配无限制，其大小受到服务器的内存限制。）通常在投入生产的系统中，出现溢出一般都是对象分配不合理导致的。

    在此，让我们先了解下Java世界里，对象与对象管理是怎么一回事。

    在Java的体系中，所有的类作为一个对象（包括Jdk本身提供的类，应用中由开发人员编写的类），都是直接或者间接继承了Java.lang.object产生的。这些类被创建的时候都会向Jvm堆申请一定的内存空间存放，因此在Jvm堆空间里会存放各式各样的对象，有的是静态类型，有的是私有类型等等，而这些对象都是通过垃圾收集器进行管理的。

     垃圾收集器（Garbage Collection,我们通常称之为GC），它是Java与C++语言的一个显著的不同点。Java语言通过垃圾收集器管理内存中的对象，垃圾收集器是在C++基础上的一种极大进步，使许多编程问题消失于无形中。通过垃圾回收，在Java编程过程中，内存漏洞的情况会少得多。

    虽然垃圾收集器为开发带来了极大的便利，但如果对象分配与使用不合理，也会导致垃圾回收在性能上拖Jvm的后腿。为了解决性能问题，GC则是一个让我们不能忽视的问题。根据不同的应用场景，选择适合的GC策略，可以帮助系统性能在一定程度上得到显著的优化。

    垃圾收集器为了快速清除在JVM堆中不再使用的对象，从而释放出空间来供其他请求创建对象，常见的方法有引用计数方法和对象引用遍历方法等算法，目前主流的方法为对象引用遍历方法。通过这些高效的算法实现的GC策略有许多种，他们都是针对各种应用场景而产生的，我们可以通过在JVM启动参数中设置，来调整GC策略。

    在IBM SDK 5.0提供了四种不同的GC策略优化配置(IBM 在WebSphere 6.1版本开始，IBM JDK 升级到IBM SDK5.0，也就是常说的JDK1.5)，详细如下：

序号策略选项描述备注
1针对吞吐量进行优化-Xgcpolicy:optthruputWAS默认策略。对于吞吐量比短暂的 GC 停顿更重要的应用程序，通常使用这种策略。每当进行垃圾收集时，应用程序都会停顿。 
2针对停顿时间进行优化-Xgcpolicy:optavgpause通过并发地执行一部分垃圾收集，在高吞吐量和短 GC 停顿之间进行折中。应用程序停顿的时间更短。 
3分代并发-Xgcpolicy:gencon以不同方式处理短期存活的对象和长期存活的对象。采用这种策略时，具有许多短期存活对象的应用程序会表现出更短的停顿时间，同时仍然产生很好的吞吐量。推荐使用
4子池-Xgcpolicy:subpool采用与默认策略相似的算法，但是采用一种比较适合多处理器计算机的分配策略。建议对于有 16 个或更多处理器的 SMP 计算机使用这种策略。这种策略只能在 IBM pSeries® 和 zSeries® 平台上使用。需要扩展到大型计算机上的应用程序可以从这种策略中受益。 


   在Sun Jvm也有自己特色的GC策略，如：
序号策略选项描述备注
1并发收集器-XX:+UseConcMarkSweepGC并发收集器与应用程序同时运行。这些收集器在某点上（比如压缩时），一般都不得不停止其他操作，以完成特定的任务，但是因为其他应用程序可进行其他的后台操作，所以中断其他处理的实际时间大大降低。 
2并行收集器-XX:+UseParallelGC并行收集器使用某种传统的算法，并使用多线程并行地执行它们的工作。在多cpu机器上使用多线程技术可以显著的提高java应用程序区性的可扩展性。 
3串行收集器-XX:+UseSerialGC用单线程处理所有垃圾回收工作，因为无需多线程交互，所以效率比较高。但是，也无法使用多处理器的优势，所以此收集器适合单处理器机器。当然，此收集器也可以用在小数据量（100M左右）情况下的多处理器机器上。 


  通过以上的列表数据，大家也接触到了各种常见的GC策略，相信到此对GC与GC策略也有了一定程度的了解。那如何衡量GC的性能，如何为何业务应用选择合适的GC策略呢？

      一般来说，衡量GC效率的参数主要有2类，吞吐量和停顿时间。
     

  •    
  • 吞吐量是应用程序处理的数据量。衡量吞吐量的标准是与具体应用程序相关的。    
  • 停顿时间是垃圾收集器将所有应用程序线程停下来，从而对堆进行收集所经历的时间。 
     


      如何分析和选择适合的GC策略呢？我们可以在业务应用系统打开详细垃圾回收，收集系统在运行过程中的GC日志，通过分析GC日志，来判断当前GC策略是否符合当前应用系统。

     在实际应用场景中，不是每个应用服务都必须调整GC，如果您寄予厚望希望调了GC策略后，就一定能使系统达到性能上的提升，成效未必尽入人意。因此GC策略调整只是从GC角度去辅助性能优化，而调优的效果需要根据实际情况才能断定。例如：在测试机调整了GC策略，使用压力测试工具进行压力测试，性能优化成效显著；但在生产系统上调整了参数，却未收到让人满意成效，且生产机比测试机配置高,这些问题已经是屡见不鲜了，问题原因有很多方面，通常是因为生产实际使用场景与测试机压力测试场景不一致，系统受到的压力不一样所导致的。

      但GC调整在系统能够性能调优上确是一个必不可少的环节，合理的创建使用对象，选择适合的GC策略，往往能让性能有一定的提高，也减少了内存溢出的可能性，或者缩短系统停顿的时间。

      以下是一段发生在IBM SDK5.0版本上配置了分代并发策略所产生的GC日志，让我们一起看下如何分析这一段GC：
Xml代码 复制代码 收藏代码
  1. <!—距离上次GC间隔时间为6.787 秒  
  2. <af> 表示本次垃圾回收是因为分配失败而引发的，如果标签开头写着sys，则表示应用中有显示调用GC,如System.gc()。一般情况下不建议显示调用GC,当然也可以通过配置防止显示GC, 在JVM启动参数中加入-Xdisableexplicitgc参数屏蔽显式GC。 
  3. Type=“nursery” ：这次GC的类型是新生代方式,因为新生代的分配失败而进行垃圾回收了。 
  4. Id=”3365”代表GC发生在新生代，已经重复执行了3365次 
  5. timestamp：GC的执行时间 
  6. --> 
  7. <af type="nursery"id="3365"timestamp="三  1月 06 16:09:03 2010"intervalms="6787.454"> 
  8.  
  9. <!—这里记录需要申请的堆大小为710824b 约694KB --> 
  10. <minimum requested_bytes="710824"/> 
  11.  
  12. <!—GC准备开始前 使用时间为 0.224秒 --> 
  13. <time exclusiveaccessms="0.224"/> 
  14.  
  15. <!—GC前堆空间使用情况，可以看到剩余567408B，不能满足空间的申请要求了，申请空间是710824B，因此就需要进行GC --> 
  16.   <nurseryfreebytes="567408"totalbytes="42694656"percent="1"/> 
  17.  
  18.   <!--   GC前的堆空间情况，JVM堆大小为1.2左右了，空闲的空间为650mb左右，大致空闲空间为48% 
  19. Tenured：长存（tenured） 区域 
  20. Soa:小对象使用区域；就是 “正常的” 堆。所有对象最初都分配给小对象区域，但是如果小区域已经分配完了，则将大于 64KB 的对象分配给大对象区域。 
  21. Loa：大对象使用区域；大对象区域是堆中保留给大对象分配的一小片区域。如果应用程序不需要大对象区域（也就是应用程序不分配任何大对象），内存管理例程会快速将大对象区域缩减为空，这样，整个堆都可以供 “正常的” 分配使用。 
  22. --> 
  23.   <tenuredfreebytes="666933424"totalbytes="1365881856"percent="48"> 
  24.     <soa freebytes="654641328"totalbytes="1353589760"percent="48"/> 
  25.     <loa freebytes="12292096"totalbytes="12292096"percent="100"/> 
  26.   </tenured> 
  27.  
  28. <!—GC后堆空间使用情况 --> 
  29. <!—详细gc情况  
  30. type="scavenger"：垃圾回收类型为清理过程。 
  31. id="3365": 意为执行力3365次清理，并且没有发生过全局GC，如<gc type=”global”>。 
  32. <flipped objectcount="15558"bytes="3973128"/>：说明将要把15558个存活下来的对象被复制到了幸存区（survivor space） 
  33. <tenured objectcount="14791"bytes="14233400"/>：说明将要把14791个对象则经过多次幸存区的复制，被转移到了长存区（tenured） 
  34.   
  35. <scavengertiltratio="65"/>:清理的倾斜比率为65% 
  36. <refs_clearedsoft="73"weak="61"phantom="0"/>：清理了存在引用对象的数目. 弱引用为61、软引用为73，和虚引用为0. 弱引用、软引用和虚引用允许灵活的缓存，能够改进应用程序的内存特性。如果引用对象过多大于1000，GC停顿时间就会受到影响。因此我们需要检查是否存在过多的应用对象。 
  37. <finalizationobjectsqueued="40"/>：收尾器，存在需要在GC后，要调用的自定义方法的对象。 
  38.   
  39. --> 
  40.   <gc type="scavenger"id="3365"totalid="3709"intervalms="6788.531"> 
  41.     <flippedobjectcount="15558"bytes="3973128"/> 
  42.     <tenuredobjectcount="14791"bytes="14233400"/> 
  43.     <refs_clearedsoft="73"weak="61"phantom="0"/> 
  44.     <finalizationobjectsqueued="40"/> 
  45. <scavengertiltratio="65"/> 
  46.  
  47. <!—-GC后的情况 
  48. nursery区 
  49. 1、清理了出空闲堆大小为39108112b  约为38191.515625KB，约为37MB 
  50.    2、 总大小为44144640B,约43110KB 约为42MB 
  51. --> 
  52. <nursery freebytes="39108112"totalbytes="44144640"percent="88"tenureage="1"/> 
  53.  
  54. <!—-Tenured长存区总大小为1365881856B,约为1.27GB空闲堆大小为 651143448B  620MB--> 
  55.   
  56.     <tenuredfreebytes="651143448"totalbytes="1365881856"percent="47"> 
  57.       <soafreebytes="638851352"totalbytes="1353589760"percent="47"/> 
  58.       <loafreebytes="12292096"totalbytes="12292096"percent="100"/> 
  59.     </tenured> 
  60.     <time totalms="25.029"/> 
  61.   </gc> 
  62.  
  63. <!--这里再次打印需要申请的堆大小为710824b 约694KB --> 
  64. <minimum requested_bytes="710824"/> 
  65.  
  66. <!--通过比较，就可以知道当前次的GC情况，及堆空间的使用率 
  67. <time totalms="26.386"/> 总的GC时间为26.386ms 
  68. --> 
  69.   <nurseryfreebytes="38397288"totalbytes="44144640"percent="86"/> 
  70.   <tenuredfreebytes="651143448"totalbytes="1365881856"percent="47"> 
  71.     <soa freebytes="638851352"totalbytes="1353589760"percent="47"/> 
  72.     <loa freebytes="12292096"totalbytes="12292096"percent="100"/> 
  73.   </tenured> 
  74.   <time totalms="26.386"/> 
  75. </af> 
  76.  
  77. <!-- 经过垃圾回收，新生代的空间剩余86%，因为分配失败发生在新生代，进行的是快速的Minor gc，所以长存区的可用空间依然是47%，这次回收的时间为26.386ms。而 
  78. 在长存区发生的是Major gc，回收时间一般要长于Minor gc，一般健康的JVM 环境Minor gc：Minor gc=1：10。   --> 


     打开详细垃圾回收,我们就可以获得详细垃圾回收情况，根据以上的GC日志的分析，我们则可以了解到系统GC提供了什么样的信息给我们。通过这些信息，我们可以分析得出当前GC策略是否需要调整。(当然这个与您实际生产得出的GC日志分析结果有关)。


     在分析的过程里，我们需要关注几个点，来分析GC策略是否需要调整：
   GC频率：多长时间执行一次GC，如果GC频繁的话，则需要检查系统现在的运行情况是否合理
   GC类型+GC申请空间大小+新生代空间大小：分析GC是否合理
   各分代区域的大小：检查当前JVM堆的使用是否合理，新生代的空间大小是否符合当前业务场景要求。长存区的空间大小是否合理，再联合JVM配置的堆配置大小分析，堆的使用是否存在问题，因为虽然进行了GC，但堆空间的使用如不能满足要求的话，易导致系统出现全局GC，在压力过大的情况下还会内存溢出。
   重点检查GC过程中长存区的变化：是否存在大对象，如果有的话，可以考虑-Xlp参数优化
   GC过程中是否清理了过多引用对象：如有则需要检查应用
   GC整个过程消耗的时间是否过长：过长的GC会直接影响到系统的性能，当然这个也GC类型有关，全局GC，清理长存区的GC时间相对会长点，但是这些类型的GC不会很频繁。

     以上主要是通过详细分析GC日志，从而协助我们进一步了解到JVM堆的使用情况，最后得出当前GC策略是否符合业务应用使用场景，而更换其他GC策略则需要配合当前业务场景与JVM堆使用情况去选择适合的GC策略。

     JDK的版本不同，GC的策略配置也有所不同，但这不是重点，如何读懂GC日志，分析JVM堆的使用情况后，更根据问题去寻找适合的JVM选项参数进行设置，从各方面去调整最终达到一个性能调优的目地。

     由此可见，垃圾回收的调整在性能调优过程中也是一个十分重要的环节。

其他相关资料

适合IBM JDK 设置参数简单介绍：
序号选项描述
1-Xlp此设置与IBM JVM配合使用，以使用大页16MB来分配堆
2-Xlp64k此参数与IBM JVM配合使用，以使用64K字节页大小来分配堆
3-Xnoclassgc闭类垃圾回收，可以消除由于多次装入和卸载同一个类而造成地开销
4-Xnocompactgc该参数完全关闭压缩。虽然在性能方面有短期的好处，最终应用程序堆将变得支离破碎，即使堆中有足够的自由空间也会导致 OutOfMemory 错误
5-Xcompactgc使用该参数将导致每个垃圾收集周期都执行压缩，无论是否有必要。JVM 在压缩时要做大量的决策，在普通模式下会推迟压缩
6-Xgcthreads该参数控制 JVM 在启动过程中创建的垃圾收集帮助器线程个数。对于 N-处理器机器，默认的线程数为 N-1。这些线程提供并行标记和并行清理模式中的并行机制


适合Sun Jvm 辅助配置相关参数简单介绍：

序号选项描述
1-XX:+PrintGC输入gc收集概括。输出形式：[GC 118250K->113543K(130112K), 0.0094143 secs][Full GC 121376K->10414K(130112K), 0.0650971 secs]
2-XX:+PrintGCDetails输出Gc明细情况，输出形式：[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs][GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
3-XX:+PrintGCTimeStamps输出GC时间，输出形式：11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
4-Xloggc:filename指定输出记录文件
5-XX:+PrintGCApplicationConcurrentTime打印每次垃圾回收前，程序未中断的执行时间, 输出形式：Application time: 0.5291524 seconds
6-XX:+PrintGCApplicationStoppedTime打印垃圾回收期间程序暂停的时间。可与上面混合使用输出形式：Total time for which application threads were stopped: 0.0468229 seconds
 
7-XX:+PrintHeapAtGC打印GC前后的详细堆栈信息
8-verbose:gc详细垃圾收集信息


native_stderr.log实例
Xml代码 复制代码 收藏代码
  1. <af type="nursery"id="366"timestamp="Fri Nov 16 11:38:09 2012"intervalms="157501.087"> 
  2.   <minimumrequested_bytes="24"/> 
  3.   <time exclusiveaccessms="0.079"/> 
  4.   <nurseryfreebytes="0"totalbytes="483183616"percent="0"/> 
  5.   <tenuredfreebytes="196528288"totalbytes="536870912"percent="36"> 
  6.     <soa freebytes="169876168"totalbytes="510027776"percent="33"/> 
  7.     <loa freebytes="26652120"totalbytes="26843136"percent="99"/> 
  8.   </tenured> 
  9.   <gc type="scavenger"id="366"totalid="370"intervalms="157501.912"> 
  10.     <flippedobjectcount="204678"bytes="23822596"/> 
  11.     <tenuredobjectcount="4609"bytes="269968"/> 
  12.     <refs_clearedsoft="496"weak="848"phantom="442"/> 
  13.     <finalizationobjectsqueued="624"/> 
  14.     <scavengertiltratio="89"/> 
  15.     <nurseryfreebytes="455952320"totalbytes="483183616"percent="94"tenureage="14"/> 
  16.     <tenuredfreebytes="195859400"totalbytes="536870912"percent="36"> 
  17.       <soafreebytes="169207280"totalbytes="510027776"percent="33"/> 
  18.       <loafreebytes="26652120"totalbytes="26843136"percent="99"/> 
  19.     </tenured> 
  20.     <time totalms="33.759"/> 
  21.   </gc> 
  22.   <nurseryfreebytes="455950272"totalbytes="483183616"percent="94"/> 
  23.   <tenuredfreebytes="195859400"totalbytes="536870912"percent="36"> 
  24.     <soa freebytes="169207280"totalbytes="510027776"percent="33"/> 
  25.     <loa freebytes="26652120"totalbytes="26843136"percent="99"/> 
  26.   </tenured> 
  27.   <time totalms="41.051"/> 
  28. </af> 
  29.  
  30. <sys id="4"timestamp="Fri Nov 16 11:39:08 2012"intervalms="32322626.328"> 
  31.   <time exclusiveaccessms="0.084"/> 
  32.   <nurseryfreebytes="268060792"totalbytes="483183616"percent="55"/> 
  33.   <tenuredfreebytes="195857976"totalbytes="536870912"percent="36"> 
  34.     <soa freebytes="169205856"totalbytes="510027776"percent="33"/> 
  35.     <loa freebytes="26652120"totalbytes="26843136"percent="99"/> 
  36.   </tenured> 
  37.   <gc type="global"id="5"totalid="371"intervalms="1995627.246"> 
  38.     <compactionmovecount="5045546"movebytes="276838816"reason="compact on aggressive collection"/> 
  39.     <classloadersunloadedcount="949"timetakenms="3068.520"/> 
  40.     <refs_clearedsoft="15048"weak="1448"phantom="385"/> 
  41.     <finalizationobjectsqueued="343"/> 
  42.     <timesmsmark="402.569"sweep="7.332"compact="210.673"total="3689.986"/> 
  43.     <nurseryfreebytes="463111456"totalbytes="483183616"percent="95"/> 
  44.     <tenuredfreebytes="260923064"totalbytes="536870912"percent="48"> 
  45.       <soafreebytes="234079928"totalbytes="510027776"percent="45"/> 
  46.       <loafreebytes="26843136"totalbytes="26843136"percent="100"/> 
  47.     </tenured> 
  48.   </gc> 
  49.   <nurseryfreebytes="463111456"totalbytes="483183616"percent="95"/> 
  50.   <tenuredfreebytes="260923064"totalbytes="536870912"percent="48"> 
  51.     <soa freebytes="234079928"totalbytes="510027776"percent="45"/> 
  52.     <loa freebytes="26843136"totalbytes="26843136"percent="100"/> 
  53.   </tenured> 
  54.   <time totalms="3696.347"/> 
  55. </sys> 
  56.  
  57. <af type="nursery"id="367"timestamp="Fri Nov 16 11:41:17 2012"intervalms="187670.091"> 
  58.   <minimumrequested_bytes="443616"/> 
  59.   <time exclusiveaccessms="0.079"/> 
  60.   <nurseryfreebytes="22656"totalbytes="483183616"percent="0"/> 
  61.   <tenuredfreebytes="260921696"totalbytes="536870912"percent="48"> 
  62.     <soa freebytes="234078560"totalbytes="510027776"percent="45"/> 
  63.     <loa freebytes="26843136"totalbytes="26843136"percent="100"/> 
  64.   </tenured> 
  65.   <gc type="scavenger"id="367"totalid="372"intervalms="187677.253"> 
  66.     <flippedobjectcount="147223"bytes="21010876"/> 
  67.     <tenuredobjectcount="8855"bytes="401564"/> 
  68.     <refs_clearedsoft="831"weak="979"phantom="361"/> 
  69.     <finalizationobjectsqueued="846"/> 
  70.     <scavengertiltratio="89"/> 
  71.     <nurseryfreebytes="459584128"totalbytes="483183616"percent="95"tenureage="14"/> 
  72.     <tenuredfreebytes="259742048"totalbytes="536870912"percent="48"> 
  73.       <soafreebytes="232898912"totalbytes="510027776"percent="45"/> 
  74.       <loafreebytes="26843136"totalbytes="26843136"percent="100"/> 
  75.     </tenured> 
  76.     <time totalms="32.110"/> 
  77.   </gc> 
  78.   <nurseryfreebytes="459140512"totalbytes="483183616"percent="95"/> 
  79.   <tenuredfreebytes="259742048"totalbytes="536870912"percent="48"> 
  80.     <soa freebytes="232898912"totalbytes="510027776"percent="45"/> 
  81.     <loa freebytes="26843136"totalbytes="26843136"percent="100"/> 
  82.   </tenured> 
  83.   <time totalms="32.950"/> 
  84. </af> 
webshpere垃圾回收日志分析工具
11-03
对websphere的垃圾回收日志进行分析，知道内存的使用情况。
JVM——垃圾回收机制
码小菜（SunShuo）的先生的博客
02-20 479
重点 内存分配策略、垃圾收集器（G1）、GC算法、GC参数、对象存活的判定 垃圾回收需要思考的3件事情： 哪些内存需要回收 什么时候回收 如何回收 对象存活的判定 垃圾回收之前，要判断哪些对象需要回收。 引用计数算法 给对象添加一个引用计数器，当有引用引用这个对象时，计数器加一，当引用失效时，计数器减一，当计数器为0时，这个对象就是没有被引用的。 这种方式实现简单，判断效率也高，但是这种方式没...
websphere如何打开详细垃圾回收的开关？
Rhys learn oracle！
09-29 1993
websphere如何打开详细垃圾回收的开关？         如果您的应用程序频繁出现内存溢出（out-of-memory）的错误现象，那么为了找出问题的所在，我们必须了解内存的分配情况和使用情况，那么这时候我们就需要详细垃圾回收的信息和日志，为了得到这些信息，我们必须打开详细垃圾回收的开关。打开的步骤如下： 在管理控制台中点击服务器 > 应用服务器 > server1（或者是您自
websphere垃圾回收调优实验报告
crh198108021的博客
05-28 236
目的： 近期由于网通集中计费系统经常出现频繁的down机器情况，为了对系统进行优化调整，选择合适的参数，特生成此实验报告。处理方案： 1.修改2个WebSphere的配置: 1>.打开“详细垃圾...
WebSphere Application Server V8 中的垃圾收集，第 2 部分: 新的平衡垃圾收集选项
Shen_Guo的博客
09-11 1795
简介 在 Java™ 虚拟机 (JVM) 中，垃圾收集器减轻了应用程序开发人员的内存管理负担。垃圾收集 (GC) 是一个自动化系统，同时处理 Java 对象的内存分配和回收。这有助于降低应用程序开发的复杂性，但代价是可能在应用程序的整个生命周期中表现为不均衡的性能，以及可能影响应用程序响应能力的太长的暂停。 本系列的 第 1 部分 介绍了 IBM WebSphere Application
Java性能调优--关于垃圾回收机制的分析和指导
10-27
Java的垃圾收集器（Garbage Collector）会自动执行这一过程，减少了程序员对内存管理的直接操作，从而降低了编程错误的可能性。 然而，垃圾收集并非没有代价。它的主要缺点是可能导致程序性能下降，因为GC运行时会...
【WebSphere性能调优实践】：新手到高手的性能优化之旅，揭秘性能提升秘诀
[【WebSphere性能调优实践】：新手到高手的性能优化之旅，揭秘性能提升秘诀](https://images.surferseo.art/1d1401e5-a3dd-4848-b312-52dbb78c584c.png) # 摘要 本文全面介绍了WebSphere应用服务器的性能调优方法和...
IBM WebSphere Portal 6.1性能调优指南
调优包括但不限于调整JVM内存分配（如初始堆大小和最大堆大小）、设置垃圾收集策略、选择合适的垃圾收集器以及启用JVM的性能监控工具，以便识别和解决内存泄漏或CPU占用过高的问题。 3. **WebSphere Portal和应用...
WebSphere应用服务器V7和V8性能调优指南
- **垃圾收集器选择**：选择适合应用特性的垃圾收集器，例如CMS（Concurrent Mark Sweep）或G1（Garbage-First）收集器，以减少停顿时间。 - **JVM参数调优**：包括并行线程数、编译器级别、类加载策略等，以提高...
Java虚拟机JVM的内存分布、垃圾回收（GC）机制、新生代、老年代、永久代
waS_TransvolnoS的博客
08-29 447
如果大家想深入的了解JVM，可以读读周志明《深入理解Java虚拟机：JVM高级特性与最佳实践》 需要掌握的东西，包括以下内容、判断对象存活还是死亡的算法（引用计数算法、可达性分析算法）、常见的垃圾收集算法（复制算法、分代收集算法等以及这些算法适用于什么代）以及常见的垃圾收集器的特点（这些收集器适用于什么年代的内存收集）。 JVM内存结构由程序计数器、堆、栈、本地方法栈、方法区等部分组成，结构图如...
WebSphere Application Server V8 中的垃圾收集，第 1 部分: 使用分代收集策略作为新的默认策略
Shen_Guo的博客
09-11 2153
简介 Garbage collection (GC) 是 Java Virtual Machine (JVM) 的必要组成部分，它收集没有使用的 Java 堆内存，以便应用程序可以继续分配新的对象。GC 的效果和性能对于应用程序性能和确定 (determinism) 非常重要。IBM WebSphere Application Server V8 附带的 IBM JVM（在受支持的平台上）提供
Java性能优化的策略和常见方法（二）
困兽犹斗的专栏
09-04 1327
1）JVM对堆空间的管理 JVM在初始化的过程中分配堆。堆的大小取决于指定或者默认的最小和最大值以及堆的使用情况。如果用Heapbase表示堆底，heaptop表示堆能够增长到的最大绝对值，用heaplimit表示实际的堆顶；则两者的差值（heaptop - heapbase）由命令行参数 -Xmx决定。heaplimit指针可以随着堆的扩展而上升，随着堆的收缩而下降。heap
WAS GC 日志分析
Shen_Guo的博客
12-31 8630
WAS GC日志native_stderr.log分析          我们可以通过添加JVM启动参数 -verbose:gc 或者在管理控制台上勾选详细垃圾回收选项来打印更详细的GC日志，缺省日志记录文件是native_stderr.log文件。 不同的GC策略，日志内容会有所不同，以下是optthruput策略时，记录的详细GC日志： af（allocation fail
JVM相关参数配置和问题诊断<转>
weixin_34162228的博客
06-15 265
原文连接：http://blog.youkuaiyun.com/chjttony/article/details/6240457 1.Websphere JVM相关问题诊断： 由JVM引起的Websphere问题主要有应用服务器宕机和性能下降，JVM相关问题的特征如下： (1).Websphere应用服务器停止响应： a.Websphere服务器宕机。 b.Websphere进程挂起。 c.JVM...
WebSphere 配置&信息汇总
Markix的博客
12-09 869
IBM产品中心：https://www-945.ibm.com/support/fixcentral IBM文档中心：https://www.ibm.com/support/knowledgecenter/products/ 配置 打开类加载文件信息 Servers > Server Types(WebSphere application servers) > server1 > Configuration > Server Infrastructure > Java a.
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值