注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

和申的个人主页

专注于java开发,1985wanggang

 
 
 

日志

 
 

Full GC严重 分析结果以及解决方案  

2011-09-29 10:47:38|  分类: java调优 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

解决方法: 增加参数-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled,使CMS收集持久代的类,而不是fullgc



 

问题描述:

应用的JVM启动参数如下: -Xmx2g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k-XX:+UseConcMarkSweepGC

 


新生代:256M

旧生代:1792M(2G-256M)

持久代:128M

栈内存:256KB

新生代回收方式:并行回收

旧生代回收方式:并发回收(CMS)


JVM分代

使用内存量

内存总量

持久代

117M-125M

128M

新生代

220M-225M

256M

旧生代

800M-1G

1792M

 

 

注:明显看出,新生代以及持久代,内存使用较为紧张,旧生代较为宽裕。

 

可以改变测试环境的JVM参数,加上-XX:+PrintGCDetails -XX:+TraceClassUnloading -XX:+TraceClassLoading,看看控制台上究竟是哪些Class在不停地加/卸载,再根据这些Class找到使用该Class的地方

===========

 

Jdk1.6默认的GC优化存在bug,对大对象收集会有问题,导致内存溢出。

Wsmoree-timer出现过类似情况,去掉默认优化,Cg采用串行。

 

JDK版本1.6.0_18-b07的一个已知bug:大对象的问题或者JNI问题最终会影响CMS, G1和Parallel Garbage Collectors 这些垃圾回收策略在6u18 JDK版本上的效果。

 原文链接http://www.oracle.com/technetwork/java/javase/6u18-142093.html#bugfixes-1.6.0_18

================

 

l  解释:

持久代:131071K->103472K 总空间:131072K

旧生代:985319K->721699K 总空间:1835008K

堆内存:1152585K->721699K 总空间:2070976K

此次Full GC时间花费2.96秒,在用户态(user)占用CPU百分比2.87,系统态(sys)占用百分比0.08

l  分析:

数据很清晰了,持久代的GC是导致Full GC的原因,这和我们之前看到的类信息的加载之后又卸载之后又加载的现象是相符的。持久代空间不够,引起GC,GC回收类的信息,但是由于回收的类信息JVM之后还需要,因此JVM又去加载这些信息。JVM就在这反复加载和卸载引发大量的Full GC,消耗着系统资源,无暇响应用户的请求

jmap heap javapid 查看了当前jvm内存使用的情况,发现永久区的使用一直在增长。< xmlnamespace prefix ="o" ns ="urn:schemas-microsoft-com:office:office" />

于是在本地起searchweb服务,在env上添加-XX:+TraceClassLoading ,jboss日志里,查看到底loaded那些类,粘一段日志

[Loaded sun.reflect.GeneratedMethodAccessor395 from __JVM_DefineClass__]

[Loaded sun.reflect.GeneratedMethodAccessor396 from __JVM_DefineClass__]

[Loaded sun.reflect.GeneratedMethodAccessor397 from __JVM_DefineClass__]

[Loaded sun.reflect.GeneratedMethodAccessor398 from __JVM_DefineClass__]

[Loaded sun.reflect.GeneratedMethodAccessor399 from __JVM_DefineClass__]

[Loaded sun.reflect.GeneratedMethodAccessor400 from __JVM_DefineClass__]

[Loaded sun.reflect.GeneratedMethodAccessor401 from __JVM_DefineClass__]

[Loaded sun.reflect.GeneratedMethodAccessor402 from __JVM_DefineClass__]

[Loaded sun.reflect.GeneratedMethodAccessor403 from __JVM_DefineClass__]

[Loaded sun.reflect.GeneratedMethodAccessor404 from __JVM_DefineClass__]

[Loaded sun.reflect.GeneratedMethodAccessor405 from __JVM_DefineClass__]

[Loaded sun.reflect.GeneratedMethodAccessor406 from __JVM_DefineClass__]

[Loaded sun.reflect.GeneratedMethodAccessor407 from __JVM_DefineClass__]

[Loaded sun.reflect.GeneratedMethodAccessor408 from __JVM_DefineClass__]

[Loaded sun.reflect.GeneratedMethodAccessor409 from __JVM_DefineClass__]

[Loaded sun.reflect.GeneratedMethodAccessor410 from __JVM_DefineClass__]

[Loaded sun.reflect.GeneratedMethodAccessor411 from __JVM_DefineClass__]

发现好多的动态加载类,于是就想查下到底是什么东西产生类这么多动态加载类。

于是用jmap dump:format=b,file=heap.bin javapid  dump当前的jvm内存。

ibm的分析工具,分析出是于velocity产生的,具体是模板上引用有太多的变量属性方法,造成大量的动态类加载到jvm的永久区,也是为什么jvm的永久区内存的使用率一直在增加。

解决方法: 增加参数-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled,使CMS收集持久代的类,而不是fullgc

 

参考资料:江南白衣的— JDK5.0垃圾收集优化之--Don't Pause http://blog.csdn.net/calvinxiu/archive/2007/05/18/1614473.aspx

Eg: 如果大家还有啥好的解决方案和建议,欢迎一起讨论。

http://good.gouwuke.com

  评论这张
 
阅读(3097)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2016