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

这两种方法来解决。


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

相关推荐
TT哇1 分钟前
【多线程案例】:单例模式
java·单例模式·面试
黄焖鸡能干四碗20 分钟前
智慧教育,智慧校园,智慧安防学校建设解决方案(PPT+WORD)
java·大数据·开发语言·数据库·人工智能
lssjzmn29 分钟前
Spring Web 异步响应实战:从 CompletableFuture 到 ResponseBodyEmitter 的全链路优化
java·前端·后端·springboot·异步·接口优化
new_daimond42 分钟前
二级缓存在实际项目中的应用
java
一只乔哇噻1 小时前
java后端工程师进修ing(研一版 || day41)
java·开发语言·学习·算法
User_芊芊君子1 小时前
【Java】设计模式——单例、工厂、代理模式
java·设计模式·代理模式
2301_803554521 小时前
正向代理,反向代理,负载均衡还有nginx
java·nginx·负载均衡
要开心吖ZSH1 小时前
软件设计师备考-(十六)数据结构及算法应用(重要)
java·数据结构·算法·软考·软件设计师
向上的车轮1 小时前
基于Java Spring Boot的云原生TodoList Demo 项目,验证云原生核心特性
java·spring boot·云原生
程序员清风1 小时前
快手一面:为什么要求用Static来修饰ThreadLocal变量?
java·后端·面试