JVM系统优化实践(23):GC生产环境案例(6)

您好,这里是「码农镖局」掘金小站,欢迎您来,欢迎您再来~


在互联网大厂中,对每天亿级流量的日志进行清洗、整理是非常常见的工作。在某个系统中,需要对用户的访问日志做脱敏处理,也就是清洗掉姓名、身份证号、手机号等个人隐私信息后在保存到数据库中或者交付给其他应用使用。

系统的设计者是直接从kafka中获得的日志数据,再交由清洗系统进行处理。结构图是在这样的:

一段时间后,发现系统运行越来越慢,还出现了卡顿现象。经过调取GC日志文件后发现,业务代码中出现了大量的递归操作。于是又通过MAT工具分析OOM快照,定位递归代码产生的地方。最终,得出的结论是:递归调用次数并不是很多,几十次而已,完全在合理范围内。但递归所创建的总的char[]数组大小1G左右。由此可知,并不一定全是代码问题。继续顺着问题往下查,通过排查JVM参数的设置,发现JVM的堆内存设置过小,仅有1G,而且年轻代内存也过小。这才导致系统频繁卡顿,原来是在不停地执行GC。

所以,解决方案就非常明确了。

该系统部署在Tomcat中。解决了年轻代的问题没过多久,又出现了经常假死,但过一会又能正常访问。这就有点让人费解了。起初以为是硬件资源不足,所以使用top命令检查机器资源使用情况。针对机器配置(4C8G)和资源状况(1%CPU和50%+RAM)对系统问题进行初步排查定位。然后用通过jstat分析,没有发现新的OOM和异常的GC。通过导出内存快照,使用MAT进行分析,最终发现有太多的ClassLoader,而且每个ClassLoader都加载了大量的byte[]数组。原来,为了在系统启动时就做一些业务上的干预,开发工程师对ClassLoader做了一些自定义的修改而没有顾忌对性能的消耗。因此,解决方案也非常简单:

1、修改自定义ClassLoader的加载方式;

2、限制ClassLoader的创建数量。

再来稍微回顾一下:

GC问题定位一般会采取:

1、分析GC日志;

2、使用jstat工具;

3、使用jmap工具。

而OOM问题的分析解决,则一般会采取:

1、线上系统监控;

2、用MAT工具。

这两种方法来解决。


感谢您的大驾光临!欢迎骚扰,不胜荣幸~

相关推荐
Piper蛋窝20 分钟前
深入 Go 语言垃圾回收:从原理到内建类型 Slice、Map 的陷阱以及为何需要 strings.Builder
后端·go
勤奋的小王同学~20 分钟前
(javaEE初阶)计算机是如何组成的:CPU基本工作流程 CPU介绍 CPU执行指令的流程 寄存器 程序 进程 进程控制块 线程 线程的执行
java·java-ee
TT哇22 分钟前
JavaEE==网站开发
java·redis·java-ee
2401_8260976226 分钟前
JavaEE-Linux环境部署
java·linux·java-ee
缘来是庄1 小时前
设计模式之访问者模式
java·设计模式·访问者模式
Bug退退退1231 小时前
RabbitMQ 高级特性之死信队列
java·分布式·spring·rabbitmq
梵高的代码色盘2 小时前
后端树形结构
java
代码的奴隶(艾伦·耶格尔)2 小时前
后端快捷代码
java·开发语言
虾条_花吹雪2 小时前
Chat Model API
java
双力臂4042 小时前
MyBatis动态SQL进阶:复杂查询与性能优化实战
java·sql·性能优化·mybatis