记一次不太成功的频繁 full gc 排查过程
程序IT圈
共 2315字,需浏览 5分钟
·
2020-11-18 01:42
上周自己负责的一个应用出现频繁full gc的问题,不得不尝试优化一下。第一次做这种事只能先看看网上的文章,然后亲自尝试怎么去完成减少full gc的频率,降低young gc的频率这一目标。虽然最终只是勉强解决了,但还是希望记录下来给下一次积攒经验。
1.jps命令查看进程id
jps -l
2. jmap命令导出堆转储文件
jmap -dump:format=b,file=kfwebHeap1016.hprof 35073
3.mat工具分析堆转储文件
4.G1来了
-XX:+UseG1GC
当然只是在一台机器上作了处理,也便于与其它机器作对比。
5.MetaSpace调整
Metadata GC Threshold
由于元数据空间不足导致的GC.原来在G1中设置PermSize(永久代大小)已经没用了,取而代之的是MetaSpace参数,虽然这个用的是并非堆内存而是机器的物理内存并且最大大小没有限制,但是默认初始大小只有20m,所以要作出调整:
-XX:MetaspaceSize=128m
加了之后果然就没有出现这个问题了
6. 解决Humongous Allocation
G1 Humongous Allocation
这个是由于大型对象分配导致的问题,大型(Humongous)对象是指超过G1的Region 50%的内存对象,频繁大型对象内存内存分配会导致性能问题,而且如果一个region中大型对象过多的话则最后一个大型对内象边界和该region的边界之间的空间将不会被使用,如果有多个这样的region将会导致堆内存的碎片化,在jdk1.8u40之前这些大型对象的清理在full gc期间进行完成。较新的jvm也是把大型对象放在清理阶段,要解决上面的问题有两种方法。
1.增加region的大小(注意要在1到32m之间并且为2的整数次幂)
2.增加堆内存大小
作者:Acamy
链接:https://www.jianshu.com/p/900d7376b8b1
更多精彩: Java实战项目视频,给需要的读者,收藏!
SpringBoot 如何上传大文件?
微信支付的软件架构到底有多牛?
Java常用的几个Json库,性能强势对比!
求求你们了,别再写满屏的 if/ else 了!
基于Spring+SpringMVC+Mybatis的分布式敏捷开发系统架构(附源码)
关注公众号,查看更多优质文章
最近,整理一份Java资料《Java从0到1》,覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。 获取方式:关注公众号并回复 Java 领取,更多Java内容陆续奉上。
明天见(。・ω・。)ノ♡
更多精彩: Java实战项目视频,给需要的读者,收藏! SpringBoot 如何上传大文件? 微信支付的软件架构到底有多牛? Java常用的几个Json库,性能强势对比! 求求你们了,别再写满屏的 if/ else 了! 基于Spring+SpringMVC+Mybatis的分布式敏捷开发系统架构(附源码) 关注公众号,查看更多优质文章 最近,整理一份Java资料《Java从0到1》,覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。 获取方式:关注公众号并回复 Java 领取,更多Java内容陆续奉上。
评论