yanhongmei
yanhongmei
2012-11-23 23:01
浏览 374
已采纳

JVM高人看看这个配置是什么问题导致内存持续增长

有哪位JVM的高人能否看看我们系统下面的jvm的内存情况,到底是哪方面的问题,这个是属于正常还是不正常。非常感谢高人的指点。目前发现产品内存在持续增长。

jvm的参数配置如下:
JAVA_OPTS="-Xmx10500M -Xms10500M -Xmn600M -XX:PermSize=800M -XX:MaxPermSize=800M -Xss512K -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:/opt/itms/log/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/itms/log -Djava.util.logging.config.file=itmscpelog.properties

下面是从服务器打印的gc的log信息。

Pool: Code Cache (Non-heap memory)

    Peak Usage : init:2555904, used:16878720, committed:17104896, max:50331648
    Current Usage : init:2555904, used:16843904, committed:17104896, max:50331648


        |----------------------| committed:16.31Mb
        +---------------------------------------------------------------------+
        |//////////////////////| | max:48Mb
        +---------------------------------------------------------------------+
        |----------------------| used:16.06Mb


Pool: Par Eden Space (Heap memory)

    Peak Usage : init:209715200, used:209715200, committed:209715200, max:209715200
    Current Usage : init:209715200, used:71397896, committed:209715200, max:209715200


        |---------------------------------------------------------------------| committed:200Mb
        +---------------------------------------------------------------------+
        |/////////////////////// | max:200Mb
        +---------------------------------------------------------------------+
        |----------------------| used:68.09Mb


Pool: Par Survivor Space (Heap memory)

    Peak Usage : init:209715200, used:198330768, committed:209715200, max:209715200
    Current Usage : init:209715200, used:40336592, committed:209715200, max:209715200


        |---------------------------------------------------------------------| committed:200Mb
        +---------------------------------------------------------------------+
        |///////////// | max:200Mb
        +---------------------------------------------------------------------+
        |------------| used:38.47Mb


Pool: CMS Old Gen (Heap memory)

    Peak Usage : init:10380902400, used:7663071136, committed:10380902400, max:10380902400
    Current Usage : init:10380902400, used:7663071136, committed:10380902400, max:10380902400


        |---------------------------------------------------------------------| committed:9.67Gb
        +---------------------------------------------------------------------+
        |/////////////////////////////////////////////////// | max:9.67Gb
        +---------------------------------------------------------------------+
        |--------------------------------------------------| used:7.14Gb


Pool: CMS Perm Gen (Non-heap memory)

    Peak Usage : init:838860800, used:110594064, committed:838860800, max:838860800
    Current Usage : init:838860800, used:110594064, committed:838860800, max:838860800


        |---------------------------------------------------------------------| committed:800Mb
        +---------------------------------------------------------------------+
        |///////// | max:800Mb
        +---------------------------------------------------------------------+
        |--------| used:105.47Mb
  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 邀请回答

2条回答 默认 最新

  • tianzizhi3
    tianzizhi3 2012-11-24 12:28
    已采纳

    [quote]
    shengchuan1949:我用jmap确实发现了大对象,但这种对象好像是没有办法避免的,其中的就是HashMap对象,理论上将即便我大量使用了HashMap,虽然是强引用对象,但按道理在该方法退出时,该对象就会被回收。所以不太明白为什么垃圾回收器没有尽快的回收这些大对象。 另外,由于我们是一个并发量非常大的系统,在每个servlet创建了另一个线程A,在线程A中大量使用了HashMap,我在想是否是这个线程A没有被回收所引起的? 2 小时前
    [/quote]

    奇怪,这里怎么显示你回复的?? :oops:

    你参数里设置两种gc方式,后一个并行gc可能会覆盖前一个并发gc吧,没试过

    并行gc时,可以设置-XX:PretenureSizeThreshold来设置多大的对象直接进入老年代(单位字节) 来设置对象多大时可以直接进入年老代,你把这个值调大点,则可以保证大部分对象不会直接进入年老代,年老代的对象gc通常慢,一般内存不满时不会gc的
    所有你的大对象一直都在,不会回收
    (-XX:MaxTenuringThreshold 默认15) 这个值也可以调调,这个表示在新生代折腾多少次后进入年老代,

    gc主要在新生代,你的总共内存都成10G了,把你的新生代的参数再调大点吧-Xmn600M ,-XX:SurvivorRatio=1这个比例值最好也调一下

    点赞 评论
  • tianzizhi3
    tianzizhi3 2012-11-24 00:19

    Pool: CMS Old Gen (Heap memory)

        Peak Usage : init:10380902400, used:7663071136, committed:10380902400, max:10380902400 
        Current Usage : init:10380902400, used:7663071136, committed:10380902400, max:10380902400 
    
    
            |---------------------------------------------------------------------| committed:9.67Gb 
            +---------------------------------------------------------------------+ 
            |/////////////////////////////////////////////////// | max:9.67Gb 
            +---------------------------------------------------------------------+ 
            |--------------------------------------------------| used:7.14Gb 
    

    年老代慢慢多了
    可能new大对象了,jmap查内存对象大小定位具体对象吧

    点赞 评论

相关推荐