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

相关推荐
wang09076 小时前
自己动手写一个spring之MVC_3
java·spring·mvc
闲猫6 小时前
Spring AI / Models / Chat Models / Ollama
java·人工智能·spring
FREEDOM_X7 小时前
Linux 多线程编程——总结
java·linux·运维·ubuntu
tmlx3I0817 小时前
Tomcat的架构设计和启动过程详解
java·tomcat
weixin_422329317 小时前
AgentScope Java 项目入门 & Builder 深度解读
java·开发语言·人工智能
shepherd1267 小时前
一次把 Spring MVC 文件上传参数“查没了”的排查:multipart、Filter 与 request body 的连环坑
java·后端·spring·mvc
宠友信息7 小时前
Spring Boot与异步审核构建仿小红书源码内容发布全流程
java·数据库·spring boot·redis·mysql·oracle·uni-app
Listen·Rain7 小时前
Springboot整合RedisStack
java·spring boot·redis
花和满楼8 小时前
K8s 1.36 ImageVolume GA:OCI 镜像不再只能跑容器
java·容器·kubernetes
头茬韭菜8 小时前
3.9 成本预警 — 退出钩子、$5 阈值对话框与多通道成本通知
java·大数据·jvm·ai