Kafka-Consumer高CPU問題分析

1、當前配置

Flink：版本1.4

Flink-Kafka-Connector：0.10.x

Kafka-Brokers:3個

Topic-Partitoins:3個

Topic-Replication:2個

2、現象描述

Flink經過Kafka-Connector鏈接Kafka消費數據，當Kafka異常，Broker節點不可用時，Kafka的Consumer線程會把Flink進程的CPU打爆至100%其中：

• 一個節點不可用時：Flink能夠恢復
• 二個節點不可用時：CPU持續100%
• 三個節點不可用時：CPU持續100%

3、問題分析：

CPU持續高，首先想到是Flink在消費數據時沒有對異常進行處理，頻繁異常打爆了CPU，咱們去檢查Flink的輸出日誌，輸出日誌並無找到有價值的信息，初次分析宣告失敗。

沒辦法，只能用動用大殺器，分析下進程的CPU佔用了線程以及堆棧

一、查看佔用CPU高的進程，確認無誤這些進程全是Flink的JOP

 

 

 

二、打印進程堆棧

jstack 10348>> 10348.txt     獲得進程的全部線程堆棧信息。

三、查找佔用CPU高的線程

ps -mp pid -o THREAD,tid,time 查找佔用cpu搞的線程

四、查看線程堆棧，發現大部分錯誤集中在KafkaConsumer.poll方法上。

 

 

到這基本能夠定位緣由了，應該是Kafka的ConsumerPoll方法致使CPU高。

圍繞KafkaConsumer須要指定排查計劃，主要是兩個方向

一、Kafka和Flink跟Poll相關的參數調整。

二、Kafka和Flink對Kafka消費時是否有Bug。

中間確實嘗試了好多條路，其中

一、驗證調整了KafkaConsumer的max.poll.interval.ms參數，不起做用。

二、Kafka的相關Jop並無進行重啓，因此不須要調整Flink重試相關的參數。

三、調整Flink的flink.poll-timeout參數，不起做用。

最終發現，原來是Kafka-Consumer0.10版本的一個Bug。

詳細的Bug描述以下：https://issues.apache.org/jira/browse/KAFKA-5766。

有了Bug解決起來就迅速多了，根據Bug制定解決驗證方案：

一、升級Flink的Kafka-ConnnectorAPI。

二、調整reconnect.backoff.ms參數。

此時升級Flink的Kafka-Connector就解決了該問題。

中間還出現一個小插曲：由於咱們的複製因子是2，當其中兩個節點宕機後，CPU也暴增到100%。增長了很多彎路。後分析，只有兩個複製因子，1個Parition分佈在兩個Broker上，假如兩個Broker宕機，實際上是和三個集羣宕機影響是同樣的。

3、過後總結

一、Kafka-Topic的複製因子和分區要根據實際須要需求設置。假若有三個節點，重要的業務Topic建議分區3個，複製因子3個，用性能換穩定。

二、Kafka的0.10版的Consumer消費時，有Bug，Broder節點異常關閉時，Client會打爆CPU，0.11及以上修復。

三、Flink版本的Kafka-Connector，0.11能夠消費0.10的Kafka.