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

您好,这里是「码农镖局」CSDN博客,欢迎您来,欢迎您再来~


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

系统的设计者是直接从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工具。

这两种方法来解决。


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

相关推荐
2301_14725836933 分钟前
7月2日作业
java·linux·服务器
香饽饽~、34 分钟前
【第十一篇】SpringBoot缓存技术
java·开发语言·spring boot·后端·缓存·intellij-idea
小莫分享38 分钟前
移除 Java 列表中的所有空值
java
2301_803554523 小时前
c++中类的前置声明
java·开发语言·c++
不想写bug呀6 小时前
多线程案例——单例模式
java·开发语言·单例模式
心平愈三千疾6 小时前
通俗理解JVM细节-面试篇
java·jvm·数据库·面试
我不会写代码njdjnssj6 小时前
网络编程 TCP UDP
java·开发语言·jvm
第1缕阳光6 小时前
Java垃圾回收机制和三色标记算法
java·jvm
funnyZpC6 小时前
好用的文档工具👉smart-doc
java
一只叫煤球的猫7 小时前
🔥 同事混用@Transactional和TransactionTemplate被我怼了,三种事务管理到底怎么选?
java·spring boot·后端