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工具。

这两种方法来解决。


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

相关推荐
邓不利东1 小时前
Spring中过滤器和拦截器的区别及具体实现
java·后端·spring
草履虫建模2 小时前
Redis:高性能内存数据库与缓存利器
java·数据库·spring boot·redis·分布式·mysql·缓存
苹果醋32 小时前
Vue3组合式API应用:状态共享与逻辑复用最佳实践
java·运维·spring boot·mysql·nginx
Micro麦可乐2 小时前
Java常用加密算法详解与实战代码 - 附可直接运行的测试示例
java·开发语言·加密算法·aes加解密·rsa加解密·hash算法
掉鱼的猫2 小时前
Java MCP 鉴权设计与实现指南
java·openai·mcp
努力的小郑2 小时前
Spring三级缓存硬核解密:二级缓存行不行?一级缓存差在哪?
java·spring·面试
手握风云-3 小时前
JavaEE初阶第七期:解锁多线程,从 “单车道” 到 “高速公路” 的编程升级(五)
java·开发语言
发仔1233 小时前
使用Canal实现MySQL到Elasticsearch数据同步
java·后端
hello早上好3 小时前
Spring AOP:从代理创建到切点匹配
java·后端·spring
psjasf13143 小时前
使用Ideal创建一个spring boot的helloWorld项目
java·spring boot·后端