性能文章>OOM案例分析之 gc overhead limit exceeded问题>

OOM案例分析之 gc overhead limit exceeded问题转载

4月前
2635110

本文来自简书tanner_li 2017年的一篇文章,一个非常典型的案例,原文在末尾。

正文:

今天生产环境出现Java.lang.OutOfMemoryErrot: GC overhead limit exceeded

网上查了资料这个错只有在java.lang.OutOfMemoryError: GC overhead limit exceeded(某项操作使用大量内存时发生)

资料:http://blog.csdn.net/jiandanjinxin/article/details/51740890

好吧,那只能先heapdump下看看到底哪个没有回收

方案一:

重启前先把修改一下tomcat的启动参数,万一再发生OOM可以自动dump堆栈信息。

1、 在tomcat启动参数中加入两个参数 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/export/home/tomcat/domains/server2/oom.hprof

2、 重启tomcat

参数说明

(1)-XX:+HeapDumpOnOutOfMemoryError 表示当JVM发生OOM时,自动生成DUMP文件。

(2)-XX:HeapDumpPath=存储文件/目录 表示生成DUMP文件的路径

方案二:

生产系统,总不能等着他当吧,既然是OOM那就先看下生产上的堆内存分配情况

jmap -heap PID

Debugger attached successfully.

Server compiler detected.

JVM version is 25.112-b15

using thread-local object allocation.

Parallel GC with 4 thread(s)

Heap Configuration:

MinHeapFreeRatio        = 0

MaxHeapFreeRatio        = 100

MaxHeapSize              = 2063597568 (1968.0MB)

NewSize                  = 42991616 (41.0MB)

MaxNewSize              = 687865856 (656.0MB)

OldSize                  = 87031808 (83.0MB)

NewRatio                = 2

SurvivorRatio            = 8

MetaspaceSize            = 21807104 (20.796875MB)

CompressedClassSpaceSize = 1073741824 (1024.0MB)

MaxMetaspaceSize        = 17592186044415 MB

G1HeapRegionSize        = 0 (0.0MB)

Heap Usage:

PS Young Generation

Eden Space:

capacity = 161480704 (154.0MB)

used    = 161480704 (154.0MB)

free    = 0 (0.0MB)

100.0% used

From Space:

capacity = 229113856 (218.5MB)

used    = 82645888 (78.8172607421875MB)

free    = 146467968 (139.6827392578125MB)

36.07197287971968% used

To Space:

capacity = 229113856 (218.5MB)

used    = 0 (0.0MB)

free    = 229113856 (218.5MB)

0.0% used

PS Old Generation

capacity = 1375731712 (1312.0MB)

used    = 1375583088 (1311.8582611083984MB)

free    = 148624 (0.1417388916015625MB)

99.98919673082305% used

23110 interned Strings occupying 2726400 bytes.

一看内存又快完了,好害怕啊,竟然大部分的堆内存都在老年代,难道是有线程还没结束,导致内存无法释放,那要再确认一下。

jmap -dump:format=b,file=文件名.hprof [pid]  

jmap的几个操作要慎用

dump很占用系统资源,可能会引起down机,但是没办法问题要查啊。

然后down到本地,用mat来分析,mat的安装办法见下:

mat安装

mat使用

打开dump文件一看,被一个填满了

再看详细的信息,发现全部是jdbc在取数据,而且线程还没结束,当然回收不了了,果然是代码有坑啊。

根据这个的数据,找到对应的脚本,并找到对应的代码,原来1000w的数据,对端系统什么条件都没带,直接来查导致内存溢出。

后面对该代码加上默认分页,问题解决。

jvm内存优化:
JAVA_OPTS="-server -Xms256m -Xmx512m -XX:PermSize=64M -XX:MaxPermSize=128m"
请先登录,再评论

👍

4月前

为你推荐

OutOfMemoryError之unable to create new native thread原因分析及6种解决方案
java.lang.OutOfMemoryError:unable to create new native thread 是比较常见的一种异常,表示应用程序无法创建新的线程。产生该异常,总体上可总结
java内存溢出问题分析过程
背景运维人员反馈一个容器化的java程序每跑一段时间就会出现OOM问题,重启后,间隔大概两天后复现。 问题调查 一、查日志由于是容器化部署的程序,登上主机后使用docker logs Containe
为什么容器内存占用居高不下,频频 OOM(续)
在之前的文章《[为什么容器内存占用居高不下,频频 OOM](https://heapdump.cn/article/1589003)》 中,我根据现状进行了分析和说明,收到了很多读者的建议和疑
Java OOM 实战篇:应用故障之Java heap space 堆溢出实战
以下是用于测试OOM的测试代码:```javapublic class HeapMemUseTest { public static void main(String[] args) {
一则OOM死机故障的处理过程
OOM是Out of Memory的简写,也就是内存不足。出现该问题的原因有很多,如程序内存泄漏等。内存泄漏问题可以通过定时地终止和重启有问题的程序来发现和解决。在比较新的Linux内核版本中,有一种
导致程序出现OOM的因素,夜深人静的时候,程序OOM异常追踪
作为Java程序员, 除了享受垃圾回收机制带来的便利外, 还深受OOM(Out Of Memory)的困惑和折磨。 堆溢出(heap)编写如下例程:```javapublic static void
导致程序出现OOM的因素,夜深人静的时候,程序OOM异常追踪
作为Java程序员, 除了享受垃圾回收机制带来的便利外, 还深受OOM(Out Of Memory)的困惑和折磨.先来看下java的内存分布 堆溢出(heap)编写如下例程:```javapublic
首次排查 OOM 实录
前言距离上篇文章更新已经一月有余,之所以一直没更新一是工作最近比较忙,二是感觉产出不了什么对自己和他人有价值的文章。因此这段时间,主要的空闲时间在学习技术和写 GitHub,博客这边就暂时落下了。本篇