一次Kafka内存泄露排查经过

Posted 阿维

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了一次Kafka内存泄露排查经过相关的知识,希望对你有一定的参考价值。

现象:

 

 

2月11号数据:

 

 

2月14号数据:

 

2月15号数据:

 

 

可以看到newPartitionProducer持续增长,可定位到是kafka的问题。

最近增加的topic:ai_face_process_topic

 

 

2022.1.25上线到今天2022.2.15一共20天,只增长了701个视频,平均每天35个视频。

但这个topic有64个分区。

根据sarama客户端的API,给每个分区发消息时会判断这个分区的handler是否存在,不存在则创建。且创建后需要手动close,否则内存一直占用。

 

 

而sarama的partitioner是NewRandomPartitioner随机匹配,所以出现前几天新增分配二三十个handler,直到分配完64个handler。

关键代码:

handler := tp.handlers[msg.Partition]
        if handler == nil
            handler = tp.parent.newPartitionProducer(msg.Topic, msg.Partition)
            tp.handlers[msg.Partition] = handler
        

 

结论:

增长几天稳定后则不会继续增长。

 

其他分区数比较多的topic没有观察到内存持续增长情况是因为数据量比较大,服务启动没多久就分配完了每个分区的handler。

 

优化:

后面ai_face_process_topic考虑迁移到redis做消息中转。

 

参考链接:

sarama API

githup sarama memory leak问题

kafka memory leak问题

 

以上是关于一次Kafka内存泄露排查经过的主要内容,如果未能解决你的问题,请参考以下文章

一次漫长的dubbo网关内存泄露排查经历

一次诡异的内存泄露排查过程,背后原因令人深思

一次golang sarama kafka内存占用大的排查经历

线上问题排查内存泄漏排查(模拟真实环境)

一次线上kafka消费问题排查

如何排查Java内存泄露