程序刚启动,发生三次FullGc的问题追踪

简介: 程序刚启动,发生三次FullGc的问题追踪,原因定位到JVM的默认参数Metaspace初始值和最大值是需要设置

问题现象

fe55baf9-d4d3-4765-a805-689b867b2386.png

从截图可以看出,程序刚启动发生了3次FullGc, 13次YGC

开启打印GC日志的命令

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps

GC详细日志如下
[GC (Allocation Failure) [PSYoungGen: 65536K->6408K(76288K)] 65536K->6416K(251392K), 0.0148227 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 
[GC (Allocation Failure) [PSYoungGen: 71944K->10063K(76288K)] 71952K->10151K(251392K), 0.0088836 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
[GC (Metadata GC Threshold) [PSYoungGen: 41843K->7930K(76288K)] 41931K->8026K(251392K), 0.0055550 secs] [Times: user=0.06 sys=0.00, real=0.01 secs] 
[Full GC (Metadata GC Threshold) [PSYoungGen: 7930K->0K(76288K)] [ParOldGen: 96K->7795K(89088K)] 8026K->7795K(165376K), [Metaspace: 20582K->20568K(1067008K)], 0.0237734 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 
[GC (Allocation Failure) [PSYoungGen: 65536K->4667K(120320K)] 73331K->12471K(209408K), 0.0032643 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 119867K->10564K(136192K)] 127671K->18375K(225280K), 0.0078389 secs] [Times: user=0.03 sys=0.03, real=0.01 secs] 
[GC (Allocation Failure) [PSYoungGen: 136004K->12791K(207872K)] 143815K->21645K(296960K), 0.0098903 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
[GC (Metadata GC Threshold) [PSYoungGen: 173010K->15352K(210432K)] 181864K->24278K(299520K), 0.0093598 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
[Full GC (Metadata GC Threshold) [PSYoungGen: 15352K->0K(210432K)] [ParOldGen: 8926K->20725K(139264K)] 24278K->20725K(349696K), [Metaspace: 34021K->34007K(1079296K)], 0.0524986 secs] [Times: user=0.09 sys=0.00, real=0.05 secs]
[GC (Allocation Failure) [PSYoungGen: 195072K->11399K(306688K)] 215797K->32133K(445952K), 0.0121779 secs] [Times: user=0.02 sys=0.00, real=0.01 secs].
[GC (Allocation Failure) [PSYoungGen: 306311K->17380K(342016K)] 327045K->51832K(481280K), 0.0195859 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
[GC (Metadata GC Threshold) [PSYoungGen: 137137K->25060K(401408K)] 171589K->61916K(540672K), 0.0181306 secs] [Times: user=0.03 sys=0.03, real=0.02 secs] 
[Full GC (Metadata GC Threshold) [PSYoungGen: 25060K->0K(401408K)] [ParOldGen: 36855K->45564K(206848K)] 61916K->45564K(608256K), [Metaspace: 56321K->56281K(1099776K)], 0.1520313 secs] [Times: user=0.39 sys=0.00, real=0.15 secs]
[GC (Allocation Failure) [PSYoungGen: 400103K->16619K(488960K)] 445675K->62199K(695808K), 0.0124262 secs] [Times: user=0.06 sys=0.00, real=0.01 secs] 
[GC (Allocation Failure) [PSYoungGen: 484587K->30713K(498688K)] 530167K->82583K(705536K), 0.0273914 secs] [Times: user=0.06 sys=0.00, real=0.03 secs]

问题分析

从日志来看,FullGC三次都发生在 Full GC (Metadata GC Threshold)

old区离最大配置还很远,Metaspace区并没有真正释放空间,所以怀疑是Metaspace区不够用了

使用  java -XX:+PrintFlagsFinal -version 查看默认参数值为 21 MB,最大值为4096M = 4G

0bf6d127-25fc-450d-85e6-8201150358ef.png

翻阅资料后,得知JDK8中,-XX:MaxMetaspaceSize是没有上限的,与机器内存相关,但初始的默认值只有21M,所以得出结论是,因为metaspace空间不足导致发生了FullGC

解决方案

JDK1.8之后,永久代(PermGen)概念被废弃掉了,取而代之的是Metaspace的存储空间,它使用的是本地内存,而不是堆内存,它的大小与本地内存有关。

最终通过设置JVM启动参数-XX:MetaspaceSize=256M 解决了该问题。

-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m

67c2b55d-cdd2-49ff-8b6f-b7161a6f422b.png

483f328d-9221-4050-9567-706abed2d98d.png

目录
相关文章
|
6月前
|
Java 调度
服务器常见问题排查(一)——cpu占用高、上下文频繁切换、频繁GC
文章主要讨论了服务器中常见性能问题的一些排查思路,这篇文章主要讨论了CPU负载过高,频繁GC和频繁切换上线文这三个问题。
355 0
服务器常见问题排查(一)——cpu占用高、上下文频繁切换、频繁GC
|
11月前
|
缓存 监控 算法
因Full GC导致CPU飙升到100%问题排查记录
因Full GC导致CPU飙升到100%问题排查记录
238 0
|
11月前
|
Java
如何优化生产环境的Full GC?
大部分工程师开发完一个系统后,部署生产环境的时候往往不对JVM进行参数设置,直接用默认JVM参数,这绝对是系统负载逐渐增高的时最大问题 如你不设置-Xmx、-Xms之类的堆内存大小,你启动一个系统,可能默认就给你几百MB的堆内存大小,新生代和老年代可能都是几百M。
120 0
|
11月前
|
监控 数据可视化 Java
JVM运行状态评估及优化
估算系统QPS,每个请求会创建多少对象,占多少内存,机器配置选型,年轻代应该给多少内存,YGC触发频率,对象进入老年代的速率,老年代应该给多少内存,Full GC触发的频率。这些都是根据代码可大概合理预估的。
75 0
|
运维 监控 Kubernetes
JVM 输出 GC 日志导致 JVM 卡住
JVM 输出 GC 日志导致 JVM 卡住
JVM 输出 GC 日志导致 JVM 卡住
|
算法 Java
JVM垃圾回收机制是怎样的,何时触发YoungGC或FullGC操作,一文搞定
在垃圾回收之前,首要的问题是确定哪些垃圾需要被回收,现在Java通过根搜索算法(GC Roots Tracing)来判断一个对象是否存活,这个算法的思路就是通过一系列名为“GC Roots”的对象作为起始点,从这些节点向下搜索,当GC Roots到达不了这个某个对象时(或者说某个对象没有被任何其他对象所引用),就证明这个对象是不可用的,这些对象会被判定为需要回收的对象。
|
监控 Java 应用服务中间件
基于JavaAgent的全链路监控二《通过字节码增加监控执行耗时》
通过上一章节的介绍《嗨!JavaAgent》,我们已经知道通过配置-javaagent:文件.jar后,在java程序启动时候会执行premain方法。接下来我们使用javassist字节码增强的方式,来监控方法程序的执行耗时。
173 0
基于JavaAgent的全链路监控二《通过字节码增加监控执行耗时》
|
监控 Java 开发者
基于javaagent监控方法执行耗时
javaagent是在JDK5之后提供的新特性,也可以叫java代理。开发者通过这种机制(Instrumentation)可以在加载class文件之前修改方法的字节码(此时字节码尚未加入JVM),动态更改类方法实现AOP,提供监控服务如;方法调用时长、可用率、内存等。
400 0
基于javaagent监控方法执行耗时
|
缓存 Java
JVM频繁fullgc优化策略
JVM频繁fullgc优化策略
143 0
|
监控 Java 测试技术
系统运行缓慢,CPU 100%,以及 Full GC 次数过多问题的排查思路
处理过线上问题的同学基本上都会遇到系统突然运行缓慢,CPU 100%,以及Full GC次数过多的问题。当然,这些问题的最终导致的直观现象就是系统运行缓慢,并且有大量的报警。本文主要针对系统运行缓慢这一问题,提供该问题的排查思路,从而定位出问题的代码点,进而提供解决该问题的思路。
1107 0