-
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
2012年11月23日 23:01
2个答案 按时间排序 按投票排序
-
采纳的答案
引用
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
-
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
相关推荐
JVM配置资料JVM配置资料JVM配置资料JVM配置资料
JVM内存结构,配置参数,JVM调优监控,待完善
jvm优化;
jvm 配置jvm参数 配置jvm参数
深入详解JVM内存模型与JVM参数详细配置,感兴趣的小伙伴们可以一块学习下。
主要是JVM内存分配及简单的JVM性能调优
tomcat修改JVM内存配置(解决大项目内存溢出问题有效方案)
如何配置Tomcat的JVM虚拟机内存大小
程序运行要用到的内存大于虚拟机能提供的最大内存就发生内存溢出了, 内存溢出的问题要看业务和系统大小而定,对于某些系统可能内存溢出不常见,但某些系统还是很常见的解决的方法
jvm 内存监控
要加“m”说明是MB,否则就是KB了,在启动tomcat时会报内存不足。 -Xms:初始值 -Xmx:最大值 -Xmn:最小值 解决办法: 修改注册表HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat Service Manager\...
jvm检测工具,jconsole工具介绍,其他同类工具介绍
深入详解JVM内存模型与JVM参数详细配置.pdf
1.jvm内存结构及功能概述 2.Jvm Heap 内存结构 3.Jvm 的内存分配
jvm内存模型,jvm脑图,jvm调优,jvm垃圾回收算法,jvm垃圾回收器,逃逸算法等总结。
JVM 开发环境配置,JAVA开发环境配置
sun公司出版的jvm运行机制管理丛书,需要深入jvm的同学可以下载来看看
JVM 内存管理之道 JVM垃圾回收机制 JVM GC组合 JVM 内存监控工具
jvm内存结构
Sun JVM原理与内存管理