OutOfMemory排查

1.出现的情景:第一天测试,tps100左右,第二天测试tps5左右,平均响应时间很大。查看监控发现内存很高,CPU也70%左右。确认代码环境都没有变动。查看程序日志,发现报错,显示

Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded,查看tomcat的JVM配置,为3G,内存监控为3G,爆满。Jprofile显示char[]占用大量内存

2.排查具体class

查询原因,网上显示:

1、内存泄露,对象已经死了,无法通过垃圾收集器进行自动回收;

2、内存溢出,内存中的对象都还必须存活着,这说明Java堆分配空间不足,检查堆设置大小(-Xmx与-Xms),检查代码是否存在对象生命周期太长、持有状态时间过长的情况。

方法:

想在泄漏未发生前,取堆转储文件分析, 通过jvm参数-XX:+HeapDumpOnOutOfMemoryError(XX:+HeapDumpOnCtrlBreak不知道为什么tomcat启动不了)可以让JVM在出现内存溢出是Dump出当前的内存转储快照。

当然也可以通过用jmap生产dump文件。windows通过任务管理器查看tomcat的进程pid,linux用ps命令查看进程pid,然后用jmap命令(Java5:jmap -heap:format=b <pid>;Java6:jmap -dump:format=b,file=HeapDump.bin <pid>)

在tomcat中设置jvm参数

linux系统中

1.打开/tomcat_home/bin/catalina.sh文件

2.加上:JAVA_OPTS="$JAVA_OPTS -server -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\heapdump"

如下图位置:

注:其中不设-XX:HeapDumpPath时,dump出的文件在/tomcat_home/bin目录下

Windows系统中

1.打开/tomcat_home/bin/catalina.bat文件

2.加上:set JAVA_OPTS=%JAVA_OPTS% -server -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\heapdump

如下图位置:

分析dump出来的内存快照文件

可以使用分析工具进行分析,如:

Eclipse的MAT

下载地址:http://www.eclipse.org/mat/downloads.php

说明文档:http://www.vogella.com/articles/EclipseMemoryAnalyser/article.html#example_project

注意:解析过大的HeapDump可能导致Eclipse抛出OutOfMemory的错误。这时你需要手动调整Eclipse的缓存大小,可以参考官网给出的处理方式(原文连接

Alternatively, edit the MemoryAnalyzer.ini to contain:

-vmargs
-Xmx2g
-XX:-UseGCOverheadLimit

Eclipse插件版打不开的朋友可以试试 RPC版的MAT (我的232m的dump文件也打不开,难道非得用64bit的机器吗?):RPC版MAT下载地址 。

JProfile

时间: 2024-11-07 01:25:15

OutOfMemory排查的相关文章

位图引起的内存溢出OutOfMemory解决方案

作者:老帅 一.问题描述:Android下的相机在独自使用时,拍照没有问题,通过我们的代码调用时,也正常,但是更换了不同厂商的平板,ROM由Android4.0变成了Android4.1后,拍照出现了OutOfMemory异常,程序中断退出.如何解决这个问题呢? 二.先看看我们之前所写的代码 1) 调用系统相机(没有怀疑这里出错,代码略) 2)显示图片 mImageView = (ImageView) findViewById(R.id.imageView); fileName = mData.

内存不足(OutOfMemory)的调试分析

32位操作系统的寻址空间是4G,其中有2G被操作系统占用,也就是说留给用户进程的内存只有2G(其中还要扣除程序加载时映像占用的部分空间,一般只有1.6G~1.8G左右可以使用). 如果进程运行中需要申请内存,而操作系统无法为其分配内存空间,则会产生内存不足的异常,在.net中为System.OutOfMemoryException(The exception that is thrown when there is not enough memory tocontinue the executi

关于GC(上):Apache的POI组件导致线上频繁FullGC问题排查及处理全过程

某线上应用在进行查询结果导出Excel时,大概率出现持续的FullGC.解决这个问题时,记录了一下整个的流程,也可以作为一般性的FullGC问题排查指导. 1. 生成dump文件 为了定位FullGC的原因,首先需要获取heap dump文件,看下发生FullGC时堆内存的分配情况,定位可能出现问题的地方. 1. 1 通过JVM参数自动生成 可以在JVM参数中设置-XX:+ HeapDumpBeforeFullGC参数. 建议动态增加这个参数,直接在线上镜像中增加一方面是要重新打包发布,另一方面

linux开机获取不到IP排查思路

最近发现linux主机重启老是获取不到IP,每次都要手动dhclient eth0一下,很麻烦. 想了下,可能有问题 于是乎,就有这个排查思路: 1.查看开机时是否将网卡连接上来: 2.在虚拟机内使用命令查看,是否开机启动network服务,主要看3,5两个级别,最好开启: 3. 另外还需要看下网卡配置文件,是否配置正确,主要看 ONBOOT:开机启动网卡.这一项要是yes BOOTPROTO:网络分配方式,静态,这里需要小写,例如dhcp(dhcp自动获取),static(以静态IP方式存在)

Redis EXISTS命令耗时过长case排查

一.背景 redis慢日志分析平台上线后,随便看了一下,发现onestore使用的缓存集群,存在大量的EXISTS命令慢查询的情况: 平均每个EXISTS命令需要13ms,最大耗时近20ms.这个结果很不科学啊,EXISTS命令只是执行一次hash查找操作,应该是us级别. 和相关同学了解业务背景如下: - 业务是userfeed,存放用户发表的动态 - 使用zset存储一个用户发表的所有动态,key是用户id,集合中对应的是feedid.如果用户发表的动态很多,zset也很大 - redis集

tomcat内存占用过高排查小结

假设tomcat进程PID为16818 确认是不是内存本身分配过小:jmap -heap 16818 找到最耗内存的对象:jmap -histo 16818 (带上:live则表示先进行一次FGC再统计,如jmap -histo:live 16818) 导出内存转储快照:jmap -dump:live,format=b,file=heap.bin 16818 (使用Eclipse mat分析) 统计进程打开的句柄数:ls /proc/16818/fd |wc -l 统计进程打开的线程数:ls /

SQL Server死锁排查

1. 死锁原理 根据操作系统中的定义:死锁是指在一组进程中的各个进程均占有不会释放的资源,但因互相申请被其他进程所站用不会释放的资源而处于的一种永久等待状态. 死锁的四个必要条件:互斥条件(Mutual exclusion):资源不能被共享,只能由一个进程使用.请求与保持条件(Hold and wait):已经得到资源的进程可以再次申请新的资源.非剥夺条件(No pre-emption):已经分配的资源不能从相应的进程中被强制地剥夺.循环等待条件(Circular wait):系统中若干进程组成

nginx排查502错误

排查502错误1.查看/usr/local/nginx/conf/nginx.conf从而知道其错误日志在哪.重点查看其错误日志.2.如果是/tmp/dd.sock2017/05/01 18:48:33 [error] 2015#0: *1 access forbidden by rule, client: 192.168.81.1, server: localhost, request: "GET /favicon.ico HTTP/1.1", host: "192.168

直播疑难杂症排查(5)— 音画不同步

本文是<直播疑难杂症排查>系列的第五篇文章,我们重点来看看直播中常见的音画不同步问题. 1. 音画不同步的表现 很容易判断,就是画面和声音不匹配. 2. 音画同步的基础概念 首先我们要明白一个概念,虽然人的肉眼,很容易辨别音画是否同步的,但是机器则不然,对于播放器而言,它判断一帧视频和一帧音频是否要在同一个时间渲染和播放,依靠的完全是该数据携带的时间戳信息. 如果内容的生产端给音视频数据打的时间戳本身就有问题的话,播放器也往往无能为力了,因此,音画不同步问题,更多的时候,应该从生产端去排查原因