消息队列MQ

一次Kafka内存泄露排查经过

本文主要是介绍一次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内存泄露排查经过的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！
您可能喜欢
栏目导航