通過上一章節(jié)我們可以得到，flink把container內(nèi)存分成了8塊，一般來說我們只需要關注其中的兩塊內(nèi)存(task heap和managed)，由內(nèi)存計算公式可以看出，這兩部分是此消彼長的。

Task heap

• 默認4g的一個TM，其中大概只有35%分配給了heap內(nèi)存，一般來說對于簡單的任務足夠了，我們通過GC的情況來觀測heap內(nèi)存是否充足
• 如果我們SQL任務的計算邏輯比較復雜，比如有較多算子情況下，或者有一些維表關聯(lián)需要緩存數(shù)據(jù)，那我們就需要增大heap內(nèi)存的分配。
  1. 如果任務沒有 join，沒有 group by 等聚合算子，我們可以調(diào)小 managed 內(nèi)存分配的比例，以此來增大heap內(nèi)存的分配量(taskmanager.memory.freaction=0.4 默認)，如果內(nèi)存還是不足可以通過增加TM的總內(nèi)存
  2. 如果任務需要聚合算子，調(diào)小 managed 內(nèi)存可以導致 managed 內(nèi)存的OOM，應該直接增加TM總內(nèi)存

Managed

Flink是有狀態(tài)的計算，對于我們目前線上的使用方式，所謂的狀態(tài)使用全都依賴于 Managed 內(nèi)存，用來保存我們的一些數(shù)據(jù)和結(jié)果(例如雙流 join 時兩張表的緩存數(shù)據(jù)，group by 時使用的緩存中間結(jié)果值等)

對于有時間窗口的任務來說，狀態(tài)數(shù)據(jù)會隨著窗口的銷毀而清楚，釋放空間，但是對于沒有時間窗口的任務，我們使用TTL來進行任務狀態(tài)的清除(在sql中使用 settable.exec.state.ttl= ${time}ms) 。ttl不應設置的過大，且ttl只保證數(shù)據(jù)在設置的時間內(nèi)不會被刪除，但是何時執(zhí)行刪除動作是不確定的

由于Managed內(nèi)存是堆外內(nèi)存，flink任務本身無法很準確的進行觀測和控制，容易造成堆外內(nèi)存的使用超限。對于目前線上的運行模式(flink on yarn)，yarn會對container進程的資源消耗進行監(jiān)控，如果總內(nèi)存使用量超過申請上線，則會kill container。如果我們遇到，flink任務運行一段時間，出現(xiàn) failover，查看運行信息，報錯信息類似于 “ Connection unexpectedly closed by remote task manager 'xxx.com/xxx:'. This might indicate that the remote task manager was lost.” 一個Taskmanager丟失，很大概率是由于這個container的managed內(nèi)存用量超限被yarn kill導致，則我們應該增大內(nèi)存，。通常我們使用直接增大總內(nèi)存的方式來增加managed內(nèi)存分配，當然在heap內(nèi)存充足的情況下，也可以適當調(diào)大managed比例(taskmanager.memory.managed.fraction=0.4)的值

• TaskManager中運行多個slot和task
  slot是flink中的最小執(zhí)行資源，我們目前線上的配置為1個container設置占用1個VCORE(1個container就是1個Taskmanager)，通常情況下，為了提供cpu的利用率，默認設置1個taskmanager設為2個slot。

  如果一個任務里面有多個算子需要使用狀態(tài)存儲,比如多次group by，存在一個tm上運行多個tsdb實例,如下圖：

  
  

這個任務的配置是1個tm2個slot，并且graph中包含了3個agg算子，這表示了一個tm中會包含2*3=6個rocksdb的實例，因此此處也需要根據(jù)agg算子的類型來判定是否需要增加，常用的max，sum一般默認值足夠，如果是自定義的udaf可能需要增大managed內(nèi)存的分配

雙流的無時間窗口的join一般也需要存儲大量的數(shù)據(jù)，因此也應該適當調(diào)大managed內(nèi)存的分配。

總結(jié)

通過以上的說明，大家應該對如何配置flink tm的內(nèi)存有了一些思路。內(nèi)存是任務運行的重要資源，在任務穩(wěn)定運行，gc正常的情況下，過多的內(nèi)存分配不會增加任務的運行效率，我們在探查任務運行效率時，磁盤的IO wait，CPU的利用率，算子的執(zhí)行速度等都是需要考慮的重要因素