记录一次内存泄漏排查

事件描述

order服务出现频繁GC告警，app卡顿

事件回顾

【2024-10-21 08:20:04】order出现频繁GC告警

【2024-10-21 09:24:04】通过命令jmap -histo:live [pid]查看存活对象发现sentinel统计对象占用大量内存

【2024-10-21 10:33:04】dump下堆内存信息

【2024-10-21 10:35:04】版本由2.7.0回退到2.4.0并通知到流控群。

事件回顾（排查分析）

【2024-10-11 15:57:00】根据dump的堆内存信息排查top5对象

 

查询引用发现LongAdder最终被ClusterNode的originCountMap引用,并且这个map存储很多元素

 

 

结合OQL进行针对性搜索ClusterNode并查看属性值。发现很多此类大对象

 

结合官方文档查看ClusterNode是干嘛

 

 

结合源码查看

com.alibaba.csp.sentinel.node.ClusterNode#getOrCreateOriginNode

 

最终导致服务内存得不到释放，频繁FullGC 导致用户卡顿

结论

sentinel二期增加了来源限流,支持根据客户端ip进行拉黑和限流.使用alibaba Adapter做扩展

com.alibaba.csp.sentinel.adapter.spring.webmvc.AbstractSentinelInterceptor#preHandle

 

com.yxt.starter.sentinel.spring.web.YxtCustomRequestOriginParser#getOrigin

 

因为直接面向用户的接口，前端存在轮询接口，用户手机网络ip随着位置移动基站变更，资源随着客户端ip变更和大量用户访问导致资源的计数器持续累加并且得不到释放。

事件影响

所有app用户使用app卡顿。

 

改进措施

针对来源限流，应先判断此接口是否有配置限流和黑白名单规则，并且这个客户端ip是否配置了限流和黑名单规则，如果未配置则不进行来源访问的统计

 

判断规则是否存在