JVM成长之路,记录一次内存溢出导致频繁FGC的问题排查及解决「建议收藏」

JVM成长之路,记录一次内存溢出导致频繁FGC的问题排查及解决「建议收藏」现象:现象截图:内存:命令:jmap-heap30069GC截图:FGC次数19529次!!!何等的恐怖!!!!!命令:jstat-gcutil300691000现象描述:Node模块启动后收到请求却未能响应。一直在频繁的FGC。新生代内

大家好,又见面了,我是你们的朋友全栈君。

现象:

现象截图:

内存:

命令: jmap -heap 30069   

GC截图: 

FGC 次数 19529 次!!!何等的恐怖!!!!!

命令: jstat -gcutil 30069 1000

(小记,排查cpu100%,top  看进程cpu, top -Hp  PID 看进程内线程cpu占用, 转成16进制,用jstack查看)

现象描述:

Node模块启动后收到请求却未能响应。 一直在频繁的FGC。新生代内存爆满。老年代内存爆满!

开始分析:

启动Xmx参数为 -Xmx 128M -Xms 128M 
初步判断内存不足,第一次修改: -Xmx 256M -Xms 256M  
=============================================
运行一两天后,Node再次未响应!!!!效果仍然不好 FGC。
=============================================
使用命令查看启动参数:jps -m -l -v
30069 jars/dubhe-node-frame-1.0.0.jar com.dtwave.dipper.dubhe.node.DubheNode –spring.profiles.active=prd -Xms256m -Xmx256m -Xmn64m
 

什么情况???
新生代大小大概是 3/8  256 * 3/8 有 120M 可是却被限制到 64M ….

 

 

Xmn只分配了64M。 一旦读日志。新生代满了就直接分配到老年代了!!
于是去掉了这个参数 给Xmn一个自由!!!
=============================================
运行一两天后,Node再次未响应!!!!
=============================================

于是。给xmx翻个倍!
第二次修改:-Xmx 512M -Xms 512M
这样新生代是3/8  170M 了。这样总没问题了吧!!
=============================================

可是。。。。。。。运行一两天后,Node再次未响应!!!!看来之前的解决方法是 错的!!错的!!错的!!

根本不是什么堆空间大小的问题。

=============================================
到底是什么情况!!!!!!!!!!!!!!!!!!!!!!!!!
那就来看看堆里面到底藏了些什么!!!
执行命令:jmap -histro 14273
  1. num #instances #bytes class name
  2. ----------------------------------------------
  3.  1: 1001750 155802576 [B
  4.  2: 137954 32307952 [C
  5.  3: 983424 23602176 java.util.LinkedList$Node
  6.  4: 134617 3230808 java.lang.String
  7.  5: 34867 3091056 [Ljava.util.HashMap$Node;
  8.  6: 74748 2391936 java.util.HashMap$Node
  9.  7: 34156 1639488 java.util.HashMap
  10.  8: 8932 1523896 [Ljava.lang.Object;
  11.  9: 8216 1508664 [Ljava.util.concurrent.ConcurrentHashMap$Node;
  12.  10: 16393 1311440 org.apache.zookeeper.data.Stat
  13.  11: 35150 1124800 java.util.concurrent.ConcurrentHashMap$Node
  14.  12: 7604 847288 java.lang.Class
  15.  13: 49187 786992 java.util.concurrent.atomic.AtomicReference
  16.  14: 16393 655720 org.apache.curator.framework.recipes.cache.TreeCache$TreeNode
  17.  15: 1704 640704 java.lang.Thread
  18.  16: 8373 535872 java.util.concurrent.ConcurrentHashMap
  19.  17: 33135 530160 java.util.HashSet

这是什么???

1: 1001750 155802576 [B

果断看不出这是什么?

回忆一下:

 

比较明显的现象:

 

1. O区满的。

 

2. E区却没有满。 

[deploy@dipper_prd_2 ~]$ jstat -gccause 26003 1000

  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT    LGCC                 GCC

  0.00   0.00  58.63  99.93  97.37  96.66    280    6.302   111   37.851   44.153 Allocation Failure   No GC

 

3.FGC 次数增了,YGC倒是没有增长。

 

E区没满,O却满了。!!有什么奇怪的东西跑进了O区吗???????看了一下代码。最近Node修改的只有日志。读日志!!读日志 生成的对象 E没满 并不会进O区! 排除读日志的影响!

那 到底是什么奇怪的东西进入了O区??

看了一圈代码。发现不了问题。。

只能用终极大法了。dump堆内存分析。

dump堆内存到文件中 通过MAT软件分析。

命令: jmap –dump:format=b,file=jconsole.dump 26003

安装好eclipse的memory analysis tool (MAT),切换成mat视图。将文件导入到eclipse中。

不分析不知道。 一分析吓一跳!! 看到没有,内存中最大的那块区域!!是一个concurrentHashMap!!!!!!!!!

JVM成长之路,记录一次内存溢出导致频繁FGC的问题排查及解决「建议收藏」

JVM成长之路,记录一次内存溢出导致频繁FGC的问题排查及解决「建议收藏」

原来是有个concurrentHashMap在作怪!!

为什么这个对象会占据如此多的内存!查看代码后发现。这个concurrentHashMap 在NodeContext中。

这个数据结构存储了所有运行的作业的信息。 每新进一个 作业,会在此结构添加一个Code对象。

然而。 从未调用过remove方法!!!!!! 这块又是个单例对象的static对象,从来不会被回收。只进不出,内存溢出!Node跑一两天就完蛋!!

public class NodeContext{

 private static NodeContext ourInstance = new NodeContext();

 //存储用户的代码
 private static Map<String, Code> codesMap;

 public static NodeContext singleton() {
        return ourInstance;
 }

    private NodeContext() {
        codesMap = new ConcurrentHashMap<>();
 scheduler = SchedulerFactory.singleton().createOrGetParallelScheduler(NodeConfig.PARALLELISM_MAX_NUM);
 }

}

 

 

解决:

解决过程中又遇到了一个坑!!!

错误解决:在一个实例运行完的代码finally部分调用NodeContext.remove(codeId) 移除掉这个运行的实例!!!

发布测试环境!!! 运行报错!!!!

正确解决:

在监听实例 上报状态到ZK后再做 这个移除操作!!!

修改后的现象:

第一天:

  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT    LGCC                 GCC 

0.00  18.29  97.31  50.26  97.42  95.25     41    0.855     2    0.393    1.247 Allocation Failure   No GC

  0.00  18.29  97.80  50.26  97.42  95.25     41    0.855     2    0.393    1.247 Allocation Failure   No GC

  0.00  18.29  99.27  50.26  97.42  95.25     41    0.855     2    0.393    1.247 Allocation Failure   No GC

 21.00   0.00   0.07  50.27  96.99  95.31     42    0.879     2    0.393    1.272 Allocation Failure   No GC

 21.00   0.00   0.89  50.27  96.99  95.31     42    0.879     2    0.393    1.272 Allocation Failure   No GC

 21.00   0.00   2.12  50.27  96.99  95.31     42    0.879     2    0.393    1.272 Allocation Failure   No GC

 21.00   0.00   2.95  50.27  96.99  95.31     42    0.879     2    0.393    1.272 Allocation Failure   No GC

 21.00   0.00   3.91  50.27  96.99  95.31     42    0.879     2    0.393    1.272 Allocation Failure   No GC

 21.00   0.00   4.49  50.27  96.99  95.31     42    0.879     2    0.393    1.272 Allocation Failure   No GC

 21.00   0.00   5.10  50.27  96.99  95.31     42    0.879     2    0.393    1.272 Allocation Failure   No GC

 

 

第二天:O区只增长了2%

  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT    LGCC                 GCC

  0.00  97.82  50.26  52.21  97.59  95.44     53    1.012     2    0.393    1.405 Allocation Failure   No GC

  0.00  97.82  50.26  52.21  97.59  95.44     53    1.012     2    0.393    1.405 Allocation Failure   No GC

  0.00  97.82  50.26  52.21  97.59  95.44     53    1.012     2    0.393    1.405 Allocation Failure   No GC

  0.00  97.82  50.26  52.21  97.59  95.44     53    1.012     2    0.393    1.405 Allocation Failure   No GC

  0.00  97.82  50.26  52.21  97.59  95.44     53    1.012     2    0.393    1.405 Allocation Failure   No GC

  0.00  97.82  50.26  52.21  97.59  95.44     53    1.012     2    0.393    1.405 Allocation Failure   No GC

  0.00  97.82  50.27  52.21  97.59  95.44     53    1.012     2    0.393    1.405 Allocation Failure   No GC

  0.00  97.82  50.27  52.21  97.59  95.44     53    1.012     2    0.393    1.405 Allocation Failure   No GC

  0.00  97.82  50.27  52.21  97.59  95.44     53    1.012     2    0.393    1.405 Allocation Failure   No GC

若干天后:发生了一次FGC 但是 O区已经降低至 30.18% 到此,成功解决此内存溢出的问题!!!

[deploy@dipper_prd_2 ~]$ jstat -gcutil 3519 1000

  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT

  0.00   4.45  65.14  30.18  96.89  93.87    671    5.568     3    0.742    6.310

  0.00   4.45  65.14  30.18  96.89  93.87    671    5.568     3    0.742    6.310

  0.00   4.45  65.14  30.18  96.89  93.87    671    5.568     3    0.742    6.310

  0.00   4.45  65.15  30.18  96.89  93.87    671    5.568     3    0.742    6.310

  0.00   4.45  65.15  30.18  96.89  93.87    671    5.568     3    0.742    6.310

  0.00   4.45  65.15  30.18  96.89  93.87    671    5.568     3    0.742    6.310

  0.00   4.45  65.15  30.18  96.89  93.87    671    5.568     3    0.742    6.310

  0.00   4.45  65.15  30.18  96.89  93.87    671    5.568     3    0.742    6.310

  0.00   4.45  65.18  30.18  96.89  93.87    671    5.568     3    0.742    6.310

  0.00   4.45  65.18  30.18  96.89  93.87    671    5.568     3    0.742    6.310

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/150781.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)
blank

相关推荐

  • Mysql主主模式和主键id冲突问题

    Mysql主主模式和主键id冲突问题Mysql双机热备,简单的说,就是要保持两台数据库的数据同步。始终保持两个数据库数据一致。 主要有主备方式、双主方式;,实现双主互备,双主都可以写入;实现简单的负载均衡。问题描述:因为多主中都可以对服务器有写权限,所以设计到自增长重复问题 解决方法: 我们只要保证两台服务器上插入的自增长数据不同就可以了 如:A插入奇数ID,B插偶数ID,当然如果服务器多的话,你可以定…

  • 【mySQL】mysql数据库分页查询讨论专题

    【mySQL】mysql数据库分页查询讨论专题MySQL:limit分页公式、总页数公式1)limit分页公式(1)limit分页公式:curPage是当前第几页;pageSize是一页多少条记录limit(curPage-1)*pageSize,pageSize(2)用的地方:sql语句中select*fromstudentlimit(curPage-1)*pageSize,pageSize;2)…

  • QT常见面试题,基础知识偏多

    QT常见面试题,基础知识偏多自定义控件:应该做过吧?能举几个例子吗?还有其他的吗?你觉得自定义控件的方法主要是哪些?答:从外观设计上:QSS、继承绘制函数重绘、继承QStyle相关类重绘、组合拼装等等从功能行为上:重写事件函数、添加或者修改信号和槽等等QSS:QSS平时使用的多吗?能举几个例…

  • 实战:springboot整合rabbitMQ「建议收藏」

    实战:springboot整合rabbitMQ「建议收藏」一、RabbitMQ简述与其docker安装这里主要讲解实战整合rabbitMQ,了解RabbitMQ简述与其docker安装请点击:传送门二、springboot整合rabbitMQ1.新建springboot项目2.pom:主要添加以下两个依赖<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-

  • 常数变易法举例_常数变易法怎么想出来的

    常数变易法举例_常数变易法怎么想出来的1.4常数变易法常数变异的思考方法当程序中有许多因素都在变动的时候,我们可以假设其中的某些变数为常数,把他们写成固定的死值。将来再用变量替换。星号金字塔常数变异典型应用 打印这个金字塔:             *            **           ***           ****          **

    2022年10月28日
  • CentOS7 部署 RAID 磁盘阵列

    CentOS7 部署 RAID 磁盘阵列RAID(RedundantArrayoflndependentDisk独立冗余磁盘阵列)就是把多块独立的物理磁盘按不同的方式组合起来形成一个磁盘组(逻辑硬盘)。从而提供比单个磁盘更高的存储性能和提供数据备份技术。

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号