记录一次典型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的原因。

相关推荐
海的透彻4 小时前
dockerfile如何快速构建容器(java服务)
java·开发语言
code2cat4 小时前
Java工具篇之Gradle:用任务图组织构建与交付
java·开发语言·单元测试·gradle
后台模板学习4 小时前
大模型 Prompt 工程在电商订单系统中的踩坑记录
java·python·prompt
w_zero_one5 小时前
算法--构造
java·数据结构·算法
SL_staff5 小时前
制造业订单交付崩盘?用四层协同框架重建交付可信度(技术实践)
java·产品·全栈
SL_staff6 小时前
打破风控迭代死循环:用决策编排重构业务与技术协作链路
java·产品·全栈
Mikko76 小时前
Redis 连接数满了服务端有错误信息吗?连接数不增加却命令超时?6.2 实测连接池、超时与大 key 怎么判定
java·spring boot·redis·后端
.Bryce.6 小时前
从零到一开发技术名词大全:从需求分析到 AI Agent 工程
java·网络·人工智能·agent·需求分析·agent评测
SL_staff6 小时前
JVS-APS的7个刚性约束设计:从无限产能幻觉到可执行排产的工程实践
java·spring cloud·全栈
代码山河8 小时前
基本类型转换:自动类型转换与强制类型转换
java·学习·架构·教程·面向对象·项目