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

0 0

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

有哪位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

企业应用 JVM 内存溢出压力并发

2012年11月23日 23:01

shengchuan1949
21
0 0 3

2个答案按时间排序按投票排序

0 0

采纳的答案

引用

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

奇怪，这里怎么显示你回复的？？

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

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

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

2012年11月24日 12:28

tianzizhi
26
0 0 2

3条评论

0 0

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查内存对象大小定位具体对象吧

2012年11月24日 00:19

tianzizhi
26
0 0 2

1条评论

已解决问题

未解决问题

排行榜

查看全部排名>>