美文网首页
OOM分析 gc overhead limit exceeded

OOM分析 gc overhead limit exceeded

作者: tanner_li | 来源:发表于2017-07-12 15:19 被阅读0次

    今天生产环境出现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"

    相关文章

      网友评论

          本文标题:OOM分析 gc overhead limit exceeded

          本文链接:https://www.haomeiwen.com/subject/icebhxtx.html