Java快速开发平台

www.fastunit.com

  BlogJava :: 首页 :: 联系 :: 聚合  :: 管理
  23 Posts :: 0 Stories :: 273 Comments :: 0 Trackbacks

内存问题错综复杂,本人水平也有限,浅薄之见仅供参考。

一、GC监控

GC日志记录了内存使用和回收状态,出现内存故障时,可作为分析排查手段。

1. 启用GC监控的方法:增加java启动参数-verbose:gc,输出信息的样例:

  GC 135: total final references 4390; cleared final references 8. 
GC 135: total phantom references 0; cleared phantom references 0. 
GC 135: total old soft references 0; cleared old soft references 0. 
GC 135: total JNI global weak references 0; cleared JNI global weak references 0. 
GC 136: starting collection, maximum allocation reached. 
GC 136: live objects 1081046; collected objects 6038; collected(KB) 558. 
GC 136: queued for finalization 0; total soft references 113; cleared soft references 18. 
GC 136: current heap(KB) 716784; current threshold(KB) 262144. 
GC 136: collect (milliseconds) 1314. 
GC 136: current cycle allocation(KB) 0; previous cycle allocation(KB) 532. 
GC 136: total weak references 1321; cleared weak references 0. 

2. 将GC日志输出到文件:不同JDK设置的参数不同,参考JDK官方文档
   SUN:-Xloggc:filename (例如:-Xloggc:D:/gc.log)
   IBM:-Xverbosegc:file=filename 或 -Xverbosegclog:filename
   HP :-Xverbosegc=filename  

3. 如何设置Java启动参数:有多种方式,以下各举一例
   Tomcat:在catalina.bat的“set JAVA_OPTS=%JAVA_OPTS% ”后设置
   WebLogic:在startWebLogic.cmd的“%JAVA_HOME%\bin\java %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS% ”后设置
   WebSphere:进入管理控制台,应用服务器->进程定义->Java虚拟机高级定义

4. GC日志的图形分析工具:HP的jtune


二、内存问题描述

典型现象是系统运行一段时间后,报OutOfMemoryError错误、页面非常慢、不响应或完全不再接受请求,而此时通过观察JVM内存,发现内存急剧上升到最大值并居高不下。

这种问题出现后,往往很棘手,通常是由于应用程序不合理造成的,而不合理程序或内存泄漏的源头可能并不明显。本人的一次经历是,经过十多天各种测试手段后,最后确定问题是由一处String累加引起的,改成StringBuffer就解决了,可见,忽略“小问题”往往会带来大麻烦。

三、分析手段

1. 分析GC日志、系统日志
2. 程序中设置监控断点
3. 尽可能重现故障并同时监控JVM内存,找出引起内存急剧上升的规律
4. 检查关键程序或频繁使用的工具类的合理性

四、解决手段

1. 主要从程序入手:降低内存使用量;字符串累加时以StringBuffer代替String;随时释放不再需要的对象;SQL优化及避免频繁取出大量数据;Session中不要放大的数据。。。
2. 据WebSphere和WebLogic官方建议:通常情况下JVM的Heap最小值和最大值可设成一样(根据实际情况调整),可取系统内存的25%-75%,保证JVM有合理足够的内存大小
3. 应用服务器的其他优化措施

五、应急措施

1. 不设定JVM的最大Heap上限
2. 程序中判断内存吃紧时执行Runtime.gc()强制垃圾收集,此方式比自动收集彻底,可一定程度上改善内存利用效率
3. 在不影响业务的情况下,定期重启应用服务器

posted on 2008-01-23 13:31 FastUnit 阅读(7089) 评论(9)  编辑  收藏 所属分类: Java

Feedback

# re: 如何监控GC及内存问题解决方案 2008-01-23 13:42 BeanSoft
非常不错!  回复  更多评论
  

# re: 如何监控GC及内存问题解决方案概述 2008-01-23 15:28 dennis
据WebSphere和WebLogic官方建议:JVM的Heap最小值和最大值设成一样,这个说法是误导人的。不同的jvm的垃圾回收算法不同,甚至同一个jvm也有不同的GC算法,还是要根据实际情况调整。  回复  更多评论
  

# re: 如何监控GC及内存问题解决方案概述 2008-01-23 15:48 FastUnit
@BeanSoft
感谢老大的鼓励!

@dennis
这一点我没有太多经验无从判断,不过这确实是多位官方专家在现场给予的建议,应当是针对他们自己的产品而言。为求准确,我加上一句“通常情况下”,感谢指正!
  回复  更多评论
  

# re: 如何监控GC及内存问题解决方案概述 2008-01-23 18:19 BeanSoft
呵呵 老大不敢当 不过 JVM 参数设置的确有很多猫腻呢。。。 在以前公司搞过一阵子 Weblogic JVM 调优  回复  更多评论
  

# re: 如何监控GC及内存问题解决方案概述[未登录] 2008-01-23 20:25 吴开春
在产品运行中,仅仅为了捕获可能的泄漏问题而打开GC日志并不值得。

相对而言,在系统一个版本完成时,用内存检查工具来进行测试。在开发过程中,解决一部分泄漏问题。性价比要高一点。

实际运行过程中,如果产生泄漏必定是某一过程重复积累到一定程度导致的。往往需要结合日志从发生问题的边界点检视代码,再努力重现问题来解决。
  回复  更多评论
  

# re: 如何监控GC及内存问题解决方案概述 2008-01-24 10:27 怎么羡慕天空的飞鸟
非常感谢,  回复  更多评论
  

# re: 如何监控GC及内存问题解决方案概述 2008-01-24 15:52 FastUnit
@dennis,BeanSoft
看来还得加上dennis的一句话:根据实际情况调整。  回复  更多评论
  

# re: 如何监控GC及内存问题解决方案概述 2008-01-24 15:55 FastUnit
@吴开春
完全赞同,无论内存问题还是其他问题,越早暴露越好,也需要良好的编程习惯避免问题的产生。对于大型系统而言,在运行期间出问题往往是致命的。  回复  更多评论
  

# re: 如何监控GC及内存问题解决方案概述 2009-06-15 10:04 ufo
(web server软件)UFO不会出现一个字节的内存泄漏和一个线程的不能回收,使用UFO做Web Server的好处是网站能做得很稳定,永远也不会自己down掉;UFO在托管机房丢包率很高、遭受Hacker攻击、互联网 骨干网被黑等恶劣的环境条件下仍然能很好地运行;UFO在对付Hacker方面(防Hacker弄down和Hacker抓取不该访问的资源)也有足 够措施。
另外,UFO几乎不会进行垃圾回收,消耗CPU很少,在普通的PC Server上用UFO运行网站,平时CPU占用率<0.1%,最多时也不会超 过5%。您知道,JVM的垃圾回收会导致大量的运算,消耗很多CPU,从而导致Server的负载能力和响应速度下降。UFO在对象管理方面采 用了很好的机制和算法,做得很出色。用UFO运行网站,可以一直保证高负载能力,快速的响应速度和低CPU消耗。发布网址:www.gm365.com
  回复  更多评论
  


只有注册用户登录后才能发表评论。


网站导航: