-
服务出现频繁younggc
-
排查过程:
-
falcon中发现younggc升高
-
jmap -histo:live pid 看到存在大量char[],byte[],string
-
定位到是日志过多,执行各阶段中的日志和统计日志上报过多
-
-
解决方式:
-
增加执行日志打印开关和白名单,关闭执行日志
-
统计日志合并上报
-
-
经验沉淀:
-
梳理日志,分必要性控制打印
-
减少转JSON
-
-
-
服务出现频繁younggc
-
排查过程
-
falcon中发现younggc升高
-
jmap -histo:live pid 看到存在大量char[],byte[],string
-
怀疑日志过多引起,修改后改善不明显
-
http://jvm.sankuai.com中dump heap
-
mat打开查找较大对象,发现sql in查询过大
-
-
解决方式:
-
先降级缓存为空再查询DB逻辑
-
优化DB查询逻辑。
-
-
经验沉淀:
-
使用公司的scalpel平台可以一键dump出内存,地址:http://jvm.sankuai.com
-
mat使用
使用map工具分析内存。
-
-
3.服务每次启动时会出现一次fullgc
-
排查过程
-
falcon中发现服务每次启动时每台机器都会出现一次fullgc,之后正常。
-
jstat -gc 进程号 间隔打印时间(ms) 打印次数 ,例如 jstat -gc 31132 2000 10
发现服务metaspace已使用的内存大小为277M,再看我们的配置
-XX:MetaspaceSize=256m
-XX:MaxMetaspaceSize=512m -
发现metaspace已使用的内存大于MetaspaceSize
MetaspaceSize表示的是元空间出现首次FGC时的初始大小,如果不配置默认为20.8M,
注意:这个参数并不是我们通常意义上理解的元空间的初始大小,实际上是元空间大小和发生fullgc的阈值是不断增大的,直到MaxMetaspaceSize。
MaxMetaspaceSize是表示元空间出现FGC时最大的阈值。
-
因此是由于MetaspaceSize设置小了,在项目启动时,元空间大小已超过了我们配置的MetaspaceSize,因此触发了Metaspace的首次fullgc。
-
-
解决方式:
-
调大MetaspaceSize大小,从原来的256M,设置为512M。
-
-
经验沉淀:
-
重新理解MetaspaceSize参数。
-