一次Kafka內存泄露排查經過
一、現象
服務部署後內存總體呈上升趨勢
二、排查過程
通過go tool pprof收集了三天內存數據
2月11號數據：
2月14號數據：
2月15號數據：
可以看到newPartitionProducer持續增長，可定位到是kafka的問題。而newPartitionProducer是分區生產者，因此查看分區相關的數據。
最近增加的topic：ai_face_process_topic，這個是AI換臉的，每生成一個視頻都要通過Kafka中轉消息到視頻處理服務器。
查閱數據庫看視頻生成記錄。2022.1.25上線到今天2022.2.15一共20天，只增長了701個視頻，平均每天35個視頻。
但這個topic有64個分區。這是因為視頻生成過程比較耗時，當時考慮到需要提高並發量，所以需要分區數比較多。
查看sarama客戶端的API代碼，給每個分區發消息時會判斷這個分區的handler是否存在，不存在則創建。
sarama創建partition handler的關鍵代碼：
handler := tp.handlers[msg.Partition] if handler == nil { handler = tp.parent.newPartitionProducer(msg.Topic, msg.Partition) tp.handlers[msg.Partition] = handler } |
且創建後需要手動close，否則內存一直佔用，這是官方說明：
而我們使用sarama客戶端的producer是全局的，一直不會close，所以會一直佔用內存。
再看看我們使用sarama的partitioner是NewRandomPartitioner，即每條消息隨機匹配到partition。
這樣，按照每天三十多的視頻生成量，出現前幾天新增分配二三十個handler，逐漸減少，直到分配完64個handler。
每個handler會分配8MB內存，也就出現了上面的內存數據：152MB，264MB，172MB。
三、結論與優化
內存增長几天穩定後則不會繼續增長。
其他分區數比較多的topic沒有觀察到內存持續增長情況是因為數據量比較大，服務啟動沒多久就分配完了每個分區的handler。
優化：
單個AI換臉視頻處理服務耗時較長，決定了我們需要比較大的並發量，所以後面分區數還可能增加。而64個分區已經使每個服務佔用64*8=504MB內存，嚴重影響擴展性。
因此後面ai_face_process_topic考慮遷移到redis做消息中轉。
四、參考鏈接：
