一次应用OOM排查

前段时间系统经常出现OOM,每次出现之后系统会出现各种问题,临时解决方案只能是重启,然后等找到问题后再发布解决。

 

线上问题日志如下:

Exception in thread "msgWorkTP-811568603-1-thread-6" java.lang.OutOfMemoryError: Java heap space

Exception in thread "schedulerFactory_QuartzSchedulerThread" java.lang.OutOfMemoryError: Java heap space

Exception in thread "server-timer" java.lang.OutOfMemoryError: Java heap space

Exception in thread "Tracer-AsyncAppender-Thread-CommonAppender" java.lang.OutOfMemoryError: Java heap space

线上遇到OOM需要做两件事情第一个是dump内存,第二个是看下GC日志。 1:dump内存 使用jmap命令dump内存,需要注意的是,在linux JDK1.6某个版本里使用jmap可能会让系统挂掉,可以通过-d64来解决。

jmap -J-d64 -dump:format=b,file=dump.bin PID

一般dump下来的内存有几个G,而我这次在线上dump下来只有200M,说明jmap有问题,这个时候可以用gcore 把整个内存dump出来,然后再使用jmap把core dump转换成heap dump。命令如下:

$ jmap  -permstat  /opt/taobao/java/bin/java core.17024

因为我们没有线上权限,又担心dump的时候系统容易挂掉,所以我们在JVM里加了个参数,在OOM的时候自动dump内存,

-XX:+HeapDumpOnOutOfMemeryError

2:查看gc日志

如果没有任何JVM参数设置,gc日志默认打印在stdout.log文件里,里面可能会打其他的日志,而且GC日志也不会输出时间,所以在JVM启动参数里最好加以下命令,规范下GC日志输出到/home/admin/logs/gc.log,并且打印GC时间。

-XX:HeapDumpPath=/home/admin/logs -Xloggc:/home/admin/logs/gc.log  -XX:+PrintGCDetails -XX:+PrintGCDateStamps

在查看GC日志里发现concurrent mode failure问题,日志如下:

(concurrent mode failure): 1146697K->1146697K(1146880K), 1.0353630 secs] 1773385K->1697954K(1773568K),

这个问题是因为CMS(Concurrent Mark-Sweep)垃圾回收器在做fullgc,还没到达回收的阶段,但是年轻代又有新对象晋升到年老代,而年老代又没有足够空间了,只能全停机,进行fullgc。但是从日志上看没有释放多少空间,要么是堆不够大,要么是泄露,先调大堆,如果是泄露,还是会重现,如果不是泄露,就稳定了。于是我们进行了JVM参数调整,系统有8G内存,我们把JVM堆内存升到3.8G,修改参数XX:CMSInitiatingOccupancyFraction=60,让年老代在达到60%的时候进行CMS回收,这样在进行回收时候年老贷至少还有3800*0.4=1520m空间,就算把整个年轻代塞进去也没有问题。

-server -Xms3800m -Xmx3800m -Xmn1500m -Xss256k -XX:PermSize=340m -XX:MaxPermSize=340m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=60 -XX:+CMSClassUnloadingEnabled -XX:+DisableExplicitGC -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/admin/logs -Xloggc:/home/admin/logs/gc.log -Dcom.sun.management.jmxremote.port=9981 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dfile.encoding=UTF-8

参数调整后,过了几天还是出现OOM,可以断定是内存溢出导致的,通过自动dump下来的内存文件很快发现有一个对象占用内存非常大,解决后系统恢复正常。

转载自 并发编程网 - ifeve.com

时间: 2024-09-15 04:43:50

一次应用OOM排查的相关文章

一次线上OOM故障排查经过

转贴:http://my.oschina.net/flashsword/blog/205266   本文是一次线上OOM故障排查的经过,内容比较基础但是真实,主要是记录一下,没有OOM排查经验的同学也可以参考. 现象 我们之前有一个计算作业.最近经常出现不稳定,无法正常响应的情况.具体表现是:各种连接超时,从mysql.mongodb和zookeeper到netty,能超时的都超时过了.其他看不到太多有效的异常. 所以我们首先怀疑的是网络问题,打电话跟运维确认,运维说网络问题的可能性几乎为0,因

两个OOM Cases排查过程的分享

分享一下两个OOM Cases的查找过程,一个应用是Native OOM:另外一个应用其实没有OOM,只是每隔一段时间就会出现频繁FGC的现象,OOM的查找已经具备了不错的工具,但有些时候还是会出现很难查的现象,希望这两个排查过程的分享能给需要的同学带来一些帮助. Native OOM的排查Case 之前的几个PPT里我都说到了,目前查找Native OOM最好的方法就是用google perftools了,于是挂上google perftools,等待应用再次native oom,很幸运,两天

Apache Jmeter3.0压测数据库OOM的Bug排查

一.引言 Apache Jmeter 2.13(以下简称Jmeter2)版本后,2.X系列就作古了.前些日子,Apache Jmeter 3.0(以下简称Jmeter3)版本正式发布,新生的事物,功能肯定强大了很多,但作为开源产品,稳定性自然要打些折扣,一位同学前几天在使用Jmeter3时不幸中招. 二.问题描述 原本好用的JDBC请求脚本,压测数据库,使用Jmeter3版本时直接OOM,回退至Jmeter2,一切正常,啥也别说,肯定是又出Bug了,本着求实的精神,咱来看看Jmeter3为毛OO

zookeeper OOM问题排查

背景 最近折腾的数据库同步项目中,大量使用了zookeeper(版本3.3.3),可以说是强依赖,但是最近频频出现zookeeper内存使用率达到100%,而且是GC不掉,直接导致整个系统挂起,伤不起阿   分析 因为大部分的情况都是无法GC回收,所以很大程度上怀疑出现memory leak. 设置了jvm参数,收集了一下OOM导致jvm crash之后的日志文件进行分析 1.-XX:+HeapDumpOnOutOfMemoryError leak分析:    从leak分析来看,比较明显,99

一个比较明显的OOM的排查过程

淘江湖由于之前遇到过因爬虫导致对用户中心的访问飚高而险些发生问题的情况,所以在其最近的一个项目中升级TDDL到2.4.4版本,以使用tddl的流控功能.但是在一次压测6个小时后产生了OOM异常.用晓锋的TProfiler分析结果是: num #instances #bytes class name 1: 880137 104619672 char[] 914733 21953592 | +–java.lang.String 774175 37160400 | | +–com.**Profiler

线上PHP问题排查思路与实践

前言 前几天,在一淘网,腾讯网媒和微博商业技术联合组织的技术分享大会上,我分享了<在线PHP问题排查思路与实践>.此博文除了对PPT提供下载外,还会对ppt做简单的注释说明.主题分为三部分,常见问题,解决思路和案例分析. 常见问题 不同用户看到的错误可能不一样.一般用户看到的错误都是表层的现象.如,裸奔的错误页面: <img src="http://www.bo56.com/wp-content/uploads/2015/09/luoben.png" alt=&quo

一次数据库上云迁移性能下降的排查

背景介绍: 某客户目前正在将本地的业务系统迁移上云,测试过程中发现后台运营系统,在rds上运行时间明显要比线下PC上自建数据库运行时间要慢1倍,导致客户系统割接延期的风险.用户线下一台PC服务器的性能居然还比顶配的RDS跑的快,这让用户对RDS的性能产生了质疑,需要立刻调查原因. 问题分析: 通常SQL的执行时间在同等数据量的情况下发生变化主要有以下一些场景,其主要原因是由于优化器生成的执行计划发生了改变,这样则会导致SQL的执行时间发生较大的变化,当然可能变慢,也有可能变快,变慢是我们不想看到

Java内存溢出(OOM)异常完全指南

我的职业生涯中见过数以千计的内存溢出异常均与下文中的8种情况相关.本文分析什么情况会导致这些异常出现,提供示例代码的同时为您提供解决指南. 这也许是目前最为完整的Java OOM异常的解决指南. 1.java.lang.OutOfMemoryError:Java heap space Java应用程序在启动时会指定所需要的内存大小,它被分割成两个不同的区域:Heap space(堆空间)和Permgen(永久代): JVM内存模型示意图 这两个区域的大小可以在JVM(Java虚拟机)启动时通过参

EDAS——如何快速定位OOM问题

本期分享专家:滨雨,有多年软件开发 + 项目管理经验,先后在华为.阿里基础架构部任职,在阿里云主要从事存储.cdn.视频.中间件等技术领域的支持,喜欢新技术,喜欢钻研,喜欢各种新的挑战. 什么是OOM? 相信很多"程序猿"都能知道,OOM 异常,就是我们常见的: "java.lang.OutOfMemoryError" 在应用开发中,是比较常见的一种异常,主要分为三种: 1. OutOfMemoryError: PermGen space 2. OutOfMemor