问题描述 应用收到频繁Full GC告警 问题排查 登录到对应机器上去,查看GC日志,发现YGC一分钟已经达到了15次,比Full GC还要频繁一些,其中Full GC平均10分钟超过了4次,如下图 使用jstat -gcutil 5280 1000查看实时GC情况,年老代采用的是CMS收集器,发现触发Full GC的原因是年老代占用空间达到指定阈值70%(-XX:CMSInitiatingOccupancyFraction=70). 这时候猜测是某个地方频繁创建对象导致,通过jmap -dum…

在分享此案例前,先聊聊哪些场景会导致频繁Full GC: 内存泄漏(代码有问题,对象引用没及时释放,导致对象不能及时回收)死循环大对象程序执行了System.gc() 尤其是大对象,80%以上的情况就是他.  那么大对象从哪里来的:[1]数据库(包括 Mysql和 Mongodb等 NOSql数据库),结果集太大:[2]第三方接口传输的大对象:[3]消息队列,消息太大: 根据多年一线互联网经验,绝大部分情况是数据库大结果集导致.好,现在我们开始介绍这次线上故障: 在没有任何发布的情况下,POP(…

这个是之前处理过的一个线上问题,处理过程断断续续,经历了两周多的时间,中间各种尝试,总结如下.这篇文章分三部分: 1.问题的场景和处理过程:2.GC的一些理论东西:3.看懂GC的日志 先说一下问题吧 问题场景:线上机器在半夜会推送一个700M左右的数据,这个时候有个数据置换的过程,也就是说有700M*2的数据在heap区域中,线上系统超时比较多,导致了很严重(严重程度就不说了)的问题. 问题原因:看日志,系统接口超时的时候,系统出现了FullGC,这个时候stop-the-world了,也就停机…

一.故障现象 两个节点的ResourceManger频繁在active和standby角色中切换.不断有active易主的告警发出 许多任务的状态没能成功更新,导致一些任务状态卡在NEW_SAVING无法进入调度(还有许多资源空闲) 看了下ResourceManger的日志,发现大量以下错误: org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss zk:java…

这个是之前处理过的一个线上问题,处理过程断断续续,经历了两周多的时间,中间各种尝试,总结如下.这篇文章分三部分: 1.问题的场景和处理过程:2.GC的一些理论东西:3.看懂GC的日志 先说一下问题吧 问题场景:线上机器在半夜会推送一个700M左右的数据,这个时候有个数据置换的过程,也就是说有700M*2的数据在heap区域中,线上系统超时比较多,导致了很严重(严重程度就不说了)的问题. 问题原因:看日志,系统接口超时的时候,系统出现了FullGC,这个时候stop-the-world了,也就停机…

主要可能的原因: 1,eden区太小,eden和survivor默认比例是8:12,old区太小,新生代和老年代的比例也可以调节的.3,是否程序会分配很多短期存活的大对象,程序本身是否有问题? 进入老年区的影响因素不只是一个survivor啊.还有对象大小,存活次数,新生区老年区大小等因素.单纯改survivor大小有点盲目.还有你只是单纯的觉得full gc频繁,那你综合分析过没.是否在你压测配置的资源情况下,其实已经达到最优了?另外还可以通过其他工具检测下都是哪些对象在占用大量内存资源.  …

前几天整理了Java面试题集合,今天再来整理下Android相关的面试题集合.假设你希望能得到最新的消息,能够关注https://github.com/closedevice/interview-about,我会不断的添加和修正相关问题的描写叙述. 基础 谈谈Activity的生命周期 介绍不同场景下Activity生命周期的变化过程 启动Activity: onCreate()->onStart()->onResume(),Activity进入运行状态. Activity退居后台: 当前Ac…

以下文章来源于架构师进阶之路 ,作者二马读书 1. JVM频繁FULL GC快速排查 在分享此案例前,先聊聊哪些场景会导致频繁Full GC: 内存泄漏(代码有问题,对象引用没及时释放,导致对象不能及时回收) 死循环 大对象 尤其是大对象,80%以上的情况就是他.    那么大对象从哪里来的呢?数据库(包括Mysql和Mongodb等NOSql数据库),结果集太大:第三方接口传输的大对象:消息队列,消息太大 根据多年一线互联网经验,绝大部分情况是数据库大结果集导致. 好,现在我们开始介绍这次线上…

线上排查:内存异常使用导致full gc频繁 问题系统 日常巡检发现,应用线上出现频繁full gc 现象 应用线上出现频繁full gc 排查过程 分析dump 拉dump文件:小插曲:dump时如果指定:live,则在dump前jvm会先进行一次full gc,并且gc log里会打印dump full gc,这种对非内存泄漏导致的线上异常内存情况排查反而会带来不便,导致我们多dump了好几次. 分析dump文件: a. 发现大量long[]数组占用最大空间,有异常情况 b. 查看gc根节点…

1. 问题背景 上周线上某模块出现锁等待超时,如下图所示: 我虽然不是该模块负责人,但出于好奇,也一起帮忙排查定位问题. 这里的业务背景就是在执行到某个地方时,需要去表中插入一批数据,这批数据需要根据数据类型分配流水号.这与我的select for update引发死锁分析提到的流水号分配差不多:通过数据库悲观锁实现多实例部署的流水号生成与分配. 2. 问题排查 那么需要排查的问题很简单,为什么获取流水号的时候会发生锁等待超时? 从上面截图中的异常栈中,我们也可以看出:首先进入了带有@Trans…