背景
在大資料領域我們都知道，開發是最簡單，任務的合理調優、問題排查才是最重要的，
我們在之前的文章《Flink面試通關手冊》中也講解過，作者結合線上出現的一些問題，總結了一些任務調優需要注意的點，
一些簡單的原則
我們在之前的文章《Flink面試通關手冊》中提到過一個問題，Flink任務延遲高，想解決這個問題，你會如何入手？
當時我們給出的答案是：
在Flink的后臺任務管理中，我們可以看到Flink的哪個算子和task出現了反壓，最主要的手段是資源調優和算子調優，資源調優即是對作業中的Operator的并發數（parallelism）、CPU（core）、堆記憶體（heap_memory）等引數進行調優，作業引數調優包括：并行度的設定，State的設定，checkpoint的設定，
事實上，延遲最終的結果都是任務的最終失敗，我們在調優線上問題時，有一個最簡單的原則：
先看指標，定位問題？在看資源，是否足夠？三看吞吐，是否反壓？四看JVM，是否OOM？
輪著來，學不會轉產品吧
先看指標，定位問題
Flink 提供的 Metrics 可以在 Flink 內部收集一些指標，通過這些指標讓開發人員更好地理解作業或集群的狀態，由于集群運行后很難發現內部的實際狀況，跑得慢或快，是否例外等，開發人員無法實時查看所有的 Task 日志，比如作業很大或者有很多作業的情況下，該如何處理？此時 Metrics 可以很好的幫助開發人員了解作業的當前狀況，
再看資源，是否足夠
我們通過上述的指標定位問題時，基本可以通過延遲與吞吐指標可以對任務的性能進行精準的判斷，精確的找到問題發生的代碼位置，
一般這些位置會出現以下錯誤：
- Operator的并發數（parallelism）不合理
- CPU（core）不合理
- 堆記憶體（heap_memory）等引數設定不合理
- 并行度的設定不合理
- State的設定不合理
- checkpoint的設定不合理
我們在設定這些引數時要注意：
- 并行度（parallelism）：保證足夠的并行度，并行度也不是越大越好，太多會加重資料在多個solt/task manager之間資料傳輸壓力，包括序列化和反序列化帶來的壓力，
- CPU：CPU資源是task manager上的solt共享的，注意監控CPU的使用，
- 記憶體：記憶體是分solt隔離使用的，注意存盤大state的時候，記憶體要足夠，
- 網路：大資料處理，flink節點之間資料傳輸會很多，服務器網卡盡量使用萬兆網卡，
三看吞吐，是否反壓
關于 Flink 的反壓問題，我們之前介紹的已經夠多了，參考《Flink網路傳輸優化》
Flink 內部是基于 producer-consumer 模型來進行訊息傳遞的，Flink的反壓設計也是基于這個模型，Flink 使用了高效有界的分布式阻塞佇列，就像 Java 通用的阻塞佇列（BlockingQueue）一樣，下游消費者消費變慢，上游就會受到阻塞，
在實踐中，很多情況下的反壓是由于資料傾斜造成的，這點我們可以通過 Web UI 各個 SubTask 的 Records Sent 和 Record Received 來確認，另外 Checkpoint detail 里不同 SubTask 的 State size 也是一個分析資料傾斜的有用指標，
Flink 1.11 版本中對于 Flink 反壓問題本身做了一些優化，例如使用Unaligned Checkpoint + rocksdb生成Checkpoint，使用rocksdb快取checkpoint, 并且從原來的全量生成改為增量生成的方式, 速度更快，
另外還需要注意的是，用戶代碼的執行效率問題（頻繁被阻塞或者性能問題）和TaskManager 的記憶體以及 GC 問題，
四看JVM，是否OOM？
官網給出的引數如下：
這里面最重要的幾個：
taskmanager.memory.process.size: 512m
taskmanager.memory.framework.heap.size: 64m
taskmanager.memory.framework.off-heap.size: 64m
taskmanager.memory.jvm-metaspace.size: 64m
taskmanager.memory.jvm-overhead.fraction: 0.2
taskmanager.memory.jvm-overhead.min: 16m
taskmanager.memory.jvm-overhead.max: 64m
taskmanager.memory.network.fraction: 0.1
taskmanager.memory.network.min: 1mb
taskmanager.memory.network.max: 256mb
他們各自的意思，需要大家去查詢以下官方檔案，
JVM本身配置的主要引數無非以下這些：
堆設定
-Xms :初始堆大小
-Xmx :最大堆大小
-XX:NewSize=n :設定年輕代大小
-XX:NewRatio=n: 設定年輕代和年老代的比值，如:為3，表示年輕代與年老代比值為1：3，年輕代占整個年輕代年老代和的1/4
-XX:SurvivorRatio=n :年輕代中Eden區與兩個Survivor區的比值，注意Survivor區有兩個，如：3，表示Eden：Survivor=3：2，一個Survivor區占整個年輕代的1/5
-XX:MaxPermSize=n :設定持久代大小
收集器設定
-XX:+UseSerialGC :設定串行收集器
-XX:+UseParallelGC :設定并行收集器
-XX:+UseParalledlOldGC :設定并行年老代收集器
-XX:+UseConcMarkSweepGC :設定并發收集器
垃圾回收統計資訊
-XX:+PrintHeapAtGC GC的heap詳情
-XX:+PrintGCDetails GC詳情
-XX:+PrintGCTimeStamps 列印GC時間資訊
-XX:+PrintTenuringDistribution 列印年齡資訊等
-XX:+HandlePromotionFailure 老年代分配擔保（true or false）
并行收集器設定
-XX:ParallelGCThreads=n :設定并行收集器收集時使用的CPU數，并行收集執行緒數，
-XX:MaxGCPauseMillis=n :設定并行收集最大暫停時間
-XX:GCTimeRatio=n :設定垃圾回收時間占程式運行時間的百分比，公式為1/(1+n)
并發收集器設定
-XX:+CMSIncrementalMode :設定為增量模式，適用于單CPU情況，
-XX:ParallelGCThreads=n :設定并發收集器年輕代收集方式為并行收集時，使用的CPU數，并行收集執行緒數
我們可以利用一些簡單的JVM日志分析工具看出JVM設定的引數問題出在哪里，
總結
整體來看，Flink 的調優基本是以上的大原則，具體需要根據實際問題進行調節，另外小編不建議大家使用Scala，問題難排查，維護成本高，不要圖方便，
歡迎關注，《大資料成神之路》系列文章
歡迎關注，《大資料成神之路》系列文章
歡迎關注，《大資料成神之路》系列文章
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/246721.html
標籤：Java