事件描述
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是否配置了限流和黑名单规则,如果未配置则不进行来源访问的统计
判断规则是否存在
标签:10,ClusterNode,泄漏,2024,排查,限流,内存,sentinel From: https://www.cnblogs.com/LQBlog/p/18490319