性能文章>记一次GC频繁且间隔较长解决实战总结>

记一次GC频繁且间隔较长解决实战总结原创

2年前
726901

1.背景
XX大数据项目,进行高并发且长时间的压测验证系统稳定性的表现。

2.异常问题
压测中发现,探针监控到应用服务器集群内存消耗达到85%左右,且压测结束后内存不释放。

3.问题定位
集群中的应用服务器逐一分析,定位到41节点对应的应用服务器,GC回收Old Gen一直处于上升的趋势,Young Gen波动较小,GC频繁且GC回收间隔较长。
异常趋势图如下:
45E6FE25F8C043449F053D60A8251B13.jpeg

4.初步解决方案
-XX:NewSize=3g,-XX:MaxNewSize=3g
调优趋势图如下:
D6F7FB04685C458793F89D7EF3135D83.jpeg

5.总结
性能压测中,对于内存的要求,除了稳定不泄漏、不争Swap等,GC资源回收表现也是一个重要的指标。引起GC频繁的因素除了人为代码、脚本或程序调用的框架中调用了GC方法,内存本身也是个重要因素,当Heap设置较小或默认的过小会引起频繁的GC,所以当类似Spark、大数据、人工智能等对内存性能要求很高的相关的项目或程序时,需分配给Heap较大的内存空间,减少GC频繁导致系统出现性能异常。

请先登录,感受更多精彩内容
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得