如何监控GC及内存问题解决方案概述
2015-07-08 23:06
281 查看
内存问题错综复杂,本人水平也有限,浅薄之见仅供参考。
一、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 J***A_OPTS=%J***A_OPTS% ”后设置
WebLogic:在startWebLogic.cmd的“%J***A_HOME%\bin\java %J***A_VM% %MEM_ARGS% %J***A_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. 在不影响业务的情况下,定期重启应用服务器
一、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 J***A_OPTS=%J***A_OPTS% ”后设置
WebLogic:在startWebLogic.cmd的“%J***A_HOME%\bin\java %J***A_VM% %MEM_ARGS% %J***A_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. 在不影响业务的情况下,定期重启应用服务器
相关文章推荐
- LINUX - 基础摘要 01
- 嵌入式:Linux jffs2,yaffs2,logfs,ubifs文件系统性能分析
- Linux 解压后的启动流程分析
- Linux 内核自解压流程分析
- Linux 安装配置 JDK 8
- 比较常用的linux命令
- 我心中的核心组件(可插拔的AOP)~大话开篇及目录
- Linux文件系统详解
- 【OpenCV学习】计算两幅图像的重叠区域
- Hadoop 2.4.1 搭建Ha遇到问题记录
- Hadoop 2.4.1 搭建Ha遇到问题记录 分类: hadoop 2015-07-08 22:35 133人阅读 评论(0) 收藏
- Linux内核驱动GPIO的使用
- 基于OpenCV,简单的使用Point Grey的SDK在MFC上打开单个或多个Point Grey相机
- 大型网站图片服务器架构的演进
- Linux系统NFS故障现象
- Proxy代理(AOP实现原理)
- cacti监控工具之自定数据收集方法
- StormDRPC 概念以及简单例子测试 分类: hadoop 2015-07-08 22:10 92人阅读 评论(0) 收藏
- Tomcat配置(备忘)
- squid配置的几个例子