1. 全栈程序员必看首页

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

全栈程序员-站长 • • 未分类 • 阅读 58

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

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

发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/150781.html原文链接：https://javaforall.net

赞 (0)
全栈程序员-站长的头像全栈程序员-站长
0 0


相关推荐

  • Word 域代码：TOA（引文目录）域「建议收藏」

    Word 域代码：TOA（引文目录）域「建议收藏」

    Word 域代码：TOA（引文目录）域「建议收藏」 域代码：TOA（引文目录）域{TOC[Switches]}建立一个目录。TOC域根据标题级别、指定样式或由TC（目录项）域指定的项目来收集目录项。在使用“插入”菜单中“引用”子菜单中的“索引和目录”命令时，MicrosoftWord将插入TOC域。注释如果由TOC域创建的目录影响文档的分页，则可能需要再次更新域以得到正确的页码。开关/a标识符使

    全栈程序员-站长的头像 全栈程序员-站长
    2022年5月31日
    82
  • 网站被挂马了如何清理_网站在线挂马检测工具

    网站被挂马了如何清理_网站在线挂马检测工具

    网站被挂马了如何清理_网站在线挂马检测工具
     
    您好，今天我们讲下挂马的危害和处理办法。挂马是常见的对网站和客户都影响巨大的危害之一。
          上海快网的经验是：如果是在访问出来的源文件的头上,或是最后有被加代码,这个一般是网站文件被要改了,或是ARP,如果是源文件的很多数据位置(中间),那一般是数据库被人挂了。
         不完全统计，90%的网站都被挂过马，挂马是指在获取网站或者网站服务器的部分或者全部权限后，在网页文件中插入一段恶意代码，这些恶意代码主要是一些包括IE等漏洞利用代码，用户访问被挂马

    全栈程序员-站长的头像 全栈程序员-站长
    2022年9月30日
    2
  • jdbctemplate常用方法_cannot create jdbc driver of

    jdbctemplate常用方法_cannot create jdbc driver of

    jdbctemplate常用方法_cannot create jdbc driver of/*StreamTypeEnumValues*/varadTypeBinary=1;varadTypeText=2;/*LineSeparatorEnumValues*/varadLF=10;varadCR=13;varadCRLF=-1;/*StreamWriteEnumValues*/varadWriteChar=0;varadWriteLin…

    全栈程序员-站长的头像 全栈程序员-站长
    2022年10月14日
    2
  • python字符串替换replace函数

    python字符串替换replace函数

    python字符串替换replace函数python字符串替换replace函数replace(old,new,count)old，旧字符或字符串new，新字符或字符串count，最大替换数量，从起始位置开始计数，默认替换所有注意：replace函数替换字符串，不影响原字符串示例1：默认替换所有s1=’2019.10.30’s2=s1.replace(‘.’,’-‘)s2’2019-10-30’…

    全栈程序员-站长的头像 全栈程序员-站长
    2022年6月7日
    34
  • （8）JMeter元件详解之 Once only Controller 仅一次控制器

    （8）JMeter元件详解之 Once only Controller 仅一次控制器

    （8）JMeter元件详解之 Once only Controller 仅一次控制器

    全栈程序员-站长的头像 全栈程序员-站长
    2021年7月14日
    164
  • 荣耀20青春版曝光用屏幕指纹，网友：不是侧边指纹更快吗？「建议收藏」

    荣耀20青春版曝光用屏幕指纹，网友：不是侧边指纹更快吗？「建议收藏」

    荣耀20青春版曝光用屏幕指纹，网友：不是侧边指纹更快吗？「建议收藏」荣耀今年的手机，你会有一个共同的特征，那就是侧边指纹设计。之前采用背部指纹由于会破坏整体性，所以采用了侧边的指纹，不管是旗舰（除了去年的Magic2），还是千元机都是这种方案，荣耀官方给出的解释是，侧边指纹的解锁速度更快，而且荣耀这边还对比了相对更慢的三星S10系列的超声波方案，最终的结论是，侧边指纹完全超越了之前的三星解锁，所以让侧边指纹方案落地显得更为铿锵有力。…

    全栈程序员-站长的头像 全栈程序员-站长
    2022年8月10日
    6

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

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