中山网站建设公司排名,广州手机app软件开发,起名最好的网站排名,上海全国网站建设背景
有同学反馈收到应用RT的报警#xff0c;其中的流量都来自于网关集群中的一台机器。因为负责网关#xff0c;就上去看了下并进行排查。整体是一个比较明显的oom#xff0c;这里只是记录下排查过程#xff0c;老司机可以略过了。
初步现象
常规步骤#xff0c;使用t…背景
有同学反馈收到应用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,formatb,filexxx.xxx [pid] 打印出详细的内存堆栈拿到本地后用 IBM HeapAnalyzer比较好用 或者MAT 打开分析。 从上面比较直观看到出现oom的类。这里只是看到单个的类比较大从源码上看 会发现有块缓存没有设置长度和失效时间这个很可能是导致oom的原因。
