记录一次典型oom的处理过程

背景

有同学反馈收到应用RT的报警,其中的流量都来自于网关集群中的一台机器。因为负责网关,就上去看了下并进行排查。整体是一个比较明显的oom,这里只是记录下排查过程,老司机可以略过了。

初步现象

常规步骤,使用top 和jstat -gcutil 能直观的看到在拼命full gc。推测是出现了oom。

初步排查

一开始是用 jmap -histo:live pid >a.log 导出当前内存对象,为什么没有直接用jmap -dump:live 也是想偷懒,因为-dump 生成的文件太大,我们的服务器又跑在k8s上面,要拿回本地需要通过ftp 中转,想着能省就省。结果发现这个给后面埋了个大坑。

基于上面的结果,一度怀疑是sentinel 引起的问题。特别是对比了正常的机器上的内存分布

在上面浪费了大量时间,后面回过头看其实ConcurrentHashMap 占比这么高说明是缓存管理出现了问题。

进一步排查

老老实实用 jmap -dump:live,format=b,file=xxx.xxx pid 打印出详细的内存堆栈,拿到本地后用 IBM HeapAnalyzer(比较好用) 或者MAT 打开分析。

从上面比较直观看到出现oom的类。这里只是看到单个的类比较大,从源码上看:

会发现有块缓存没有设置长度和失效时间,这个很可能是导致oom的原因。

相关推荐
Mr数据杨2 分钟前
【Codex】用学生支持周报模块跟踪个性化支持进展
android·java·javascript·django·codex·项目开发
JavaPub-rodert9 分钟前
Apache Jena 详解:Java 开发者如何真正搭起一套知识图谱与语义服务
java·apache·知识图谱
lhldsg16 分钟前
线上住宿预约系统开发实战:从需求分析到接口设计
java·大数据·小程序·需求分析
剑指offer.40 分钟前
Linux多任务-线程篇
java·jvm·算法
2601_9620639742 分钟前
Spring Boot拦截器(Interceptor)详解
java·spring boot·后端
这是程序猿1 小时前
深入剖析Java HashMap:底层原理、数据结构与核心机制全解析
java·开发语言·数据结构
不才不才不不才1 小时前
Spring 源码系列(25): @EnableTransactionManagement 与 TransactionInterceptor
java·数据库·spring
人丰1 小时前
血泪复盘:一次由 HttpContext.Current 引发的 CPU 100% 惨案
性能优化·.net
隔窗听雨眠1 小时前
CI/CD测试数据清理完全指南:从污染根因到三层清理覆盖的完整方案
java·数据库·ci/cd
Query*1 小时前
Agent 开发之项目 AI 能力自我进化:通过浏览器自动化与数据采集实现持续学习
java·人工智能·ai·自动化