频繁Full GC(Ergonomics)----自动选择和调优引发的FullGC

通过GC日志可以获取JVM在GC时的详细信息。GC日志既可以直接在命令行输出,也可生成到指定的日志文件中。关于GC日志,可以由很多JVM参数来控制

-XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:/home/logs/gc.log
199.879: [Full GC (Ergonomics) [PSYoungGen: 64000K->63998K(74240K)] [ParOldGen: 169318K->169318K(169472K)] 233318K->233317K(243712K), [Metaspace: 20427K->20427K(1067008K)],0.1473386 secs] [Times: user=0.43 sys=0.01, real=0.15 secs]
200.027: [Full GC (Ergonomics) [PSYoungGen: 64000K->63998K(74240K)] [ParOldGen: 169318K->169318K(169472K)] 233318K->233317K(243712K), [Metaspace: 20427K->20427K(1067008K)],0.1567794 secs] [Times: user=0.41 sys=0.00, real=0.16 secs]
200.184: [Full GC (Ergonomics) [PSYoungGen: 64000K->63998K(74240K)] [ParOldGen: 169318K->169318K(169472K)] 233318K->233317K(243712K), [Metaspace: 20427K->20427K(1067008K)],0.1621946 secs] [Times: user=0.43 sys=0.00, real=0.16 secs]
200.346: [Full GC (Ergonomics) [PSYoungGen: 64000K->63998K(74240K)] [ParOldGen: 169318K->169318K(169472K)] 233318K->233317K(243712K), [Metaspace: 20427K->20427K(1067008K)],0.1547695 secs] [Times: user=0.41 sys=0.00, real=0.15 secs]
200.502: [Full GC (Ergonomics) [PSYoungGen: 64000K->63999K(74240K)] [ParOldGen: 169318K->169318K(169472K)] 233318K->233317K(243712K), [Metaspace: 20427K->20427K(1067008K)],0.1563071 secs] [Times: user=0.42 sys=0.01, real=0.16 secs]
200.659: [Full GC (Ergonomics) [PSYoungGen: 64000K->63999K(74240K)] [ParOldGen: 169318K->169318K(169472K)] 233318K->233317K(243712K), [Metaspace: 20427K->20427K(1067008K)],0.1538778 secs] [Times: user=0.42 sys=0.00, real=0.16 secs]

从上面这段输出日志中可以看到,

  • 这段日志输出的是JVM启动后200秒左右的信息
  • 在这780毫秒的实际内,JVM由于GC暂停了5次,这5次暂停都是Full GC导致的暂停。
  • 暂停的总时间为777毫秒,几乎是应用运行时间的99.6%
  • 同时,可以观察到老年代空间容量和消耗情况,在进行GC后整个老年代共169.472KB的空间被使用了169.318KB

从上面这段输出日志中我们可以知道这个应用运行状况不好,JVM几乎被垃圾回收给停止了,GC消耗了应用运行的99%的时间。并且Full GC也已经无法回收到多少内存空间了。这个应用在运行几分钟后,也抛出java.lang.OutOfMemoryError: GC overhead limit exceeded的错误并终止了。

通过分析GC日志可以发现:

  1. 应用的GC负载过高。GC暂停时间越长,应用的吞吐量越低。一般来说,GC暂停时间超过应用运行时间的10%时,该应用已经处于不正常状况了
  2. 单次暂停时间过长。单个暂停耗时越长,应用的延迟越显著。当应用的延迟性能要求应用的每次事务处理必须在1000毫秒内完成时,我们就要确保GC暂停时间不能超过1000毫秒
  3. 老年代内存使用达到极限。当发生几次Full GC后,老年代空间的内存使用仍然达到其容量极限时,我们可以知道老年代空间已经成为应用的瓶颈了。这可能是由于老年代空间分配不足,或者应用发生了内存泄漏

文章来源:https://blog.csdn.net/dabokele/article/details/61430633

 

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值