記一次 Flink 反壓問題排查過程

問題出現

根據 subtask 的 watermark 發現延遲了 10 幾分鐘，然後查看是否有異常或者 BackPressure 的情況最終發現，source->watermarks->filter 端三個 subtask 反壓都顯示 High

重啓多次，問題依然存在。

反壓的定位

正常任務 checkpoint 時間端發現非常短

反壓任務

大約可以看出來 checkpoint 做的時間過程，並且內部基本上是下游的 subtask 任務耗時比較長，因此初步懷疑是因爲下游 sink 消費原因。

分析上游的 subtask 的 Metrics

如果一個 Subtask 的發送端 Buffer 佔用率很高，則表明它被下游反壓限速了；如果一個 Subtask 的接受端 Buffer 佔用很高，則表明它將反壓傳導至上游。

outPoolUsage 和 inPoolUsage 同爲低或同爲高分別表明當前 Subtask 正常或處於被下游反壓，這應該沒有太多疑問。而比較有趣的是當 outPoolUsage 和 inPoolUsage 表現不同時，這可能是出於反壓傳導的中間狀態或者表明該 Subtask 就是反壓的根源。

如果一個 Subtask 的 outPoolUsage 是高，通常是被下游 Task 所影響，所以可以排查它本身是反壓根源的可能性。如果一個 Subtask 的 outPoolUsage 是低，但其 inPoolUsage 是高，則表明它有可能是反壓的根源。因爲通常反壓會傳導至其上游，導致上游某些 Subtask 的 outPoolUsage 爲高，我們可以根據這點來進一步判斷。值得注意的是，反壓有時是短暫的且影響不大，比如來自某個 Channel 的短暫網絡延遲或者 TaskManager 的正常 GC，這種情況下我們可以不用處理。

可以分析出來上游分下游限速裏。

通常來說，floatingBuffersUsage 爲高則表明反壓正在傳導至上游，而 exclusiveBuffersUsage 則表明了反壓是否存在傾斜（floatingBuffersUsage 高、exclusiveBuffersUsage 低爲有傾斜，因爲少數 channel 佔用了大部分的 Floating Buffer）。

分析原因

可以看出來 subtask 的數據並不是特別的傾斜

此外，最常見的問題可能是用戶代碼的執行效率問題（頻繁被阻塞或者性能問題）。最有用的辦法就是對 TaskManager 進行 CPU profile，從中我們可以分析到 Task Thread 是否跑滿一個 CPU 核：如果是的話要分析 CPU 主要花費在哪些函數里面，比如我們生產環境中就偶爾遇到卡在 Regex 的用戶函數（ReDoS）；如果不是的話要看 Task Thread 阻塞在哪裏，可能是用戶函數本身有些同步的調用，可能是 checkpoint 或者 GC 等系統活動導致的暫時系統暫停。當然，性能分析的結果也可能是正常的，只是作業申請的資源不足而導致了反壓，這就通常要求拓展並行度。值得一提的，在未來的版本 Flink 將會直接在 WebUI 提供 JVM 的 CPU 火焰圖 [5]，這將大大簡化性能瓶頸的分析。另外 TaskManager 的內存以及 GC 問題也可能會導致反壓，包括 TaskManager JVM 各區內存不合理導致的頻繁 Full GC 甚至失聯。推薦可以通過給 TaskManager 啓用 G1 垃圾回收器來優化 GC，並加上 -XX:+PrintGCDetails 來打印 GC 日誌的方式來觀察 GC 的問題。

測試解決

調整 sink to kafka 爲 print 打印控制檯

發現仍然存在反壓問題，排除 sink 寫入 kafka 速度過慢問題，因原來寫 es 存在延遲因此改爲 kafka，因此這一次先排除這個問題。

降低 cep 時間時間窗口大小，由 3 分鐘 -》1 分鐘 -》20s 反壓出現的時間越來越靠後，大體問題定位在 cep 算子相關，並且此時每次 checkpoint 的時間在增大，儘管 state 的大小相同但是時間成倍增大，故修改 checkpoint 相關配置繼續測試發現問題仍然存在

分析線程 taskmanager 線程佔比，發現 cep 算子佔用 cpu 百分之 94，故增大算子併發度 3 爲 6 線程 cpu 佔用降低如下健康狀態

反壓經歷 1 個時間也沒有再出現，後續會持續跟進，並且會嘗試調大 cep 的時間窗口，嘗試配置出最佳實踐

增大分區後發現數據傾斜嚴重，因爲 kafka 分區爲 3，但是並行度爲 6 因此 cep 算子的 6 個 subtask 數據傾斜嚴重，因此在添加 source 端執行 reblance 方法，強制輪詢方式分配數據

可以看出來這裏數據相比以前均勻很多

Cep 配置

作者：collabH
原文地址：https://github.com/collabH/repository/blob/master/bigdata/flink/practice/%E8%AE%B0%E5%BD%95%E4%B8%80%E6%AC%A1Flink%E5%8F%8D%E5%8E%8B%E9%97%AE%E9%A2%98.md

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/7FbEFpDxb1-gX0ozYxa2uA

猜你喜歡