EasyScheduler線上任務調度延遲1小時問題排查

1、背景

早上，暴躁君W來了條信息:"小時計算任務延遲一小時執行,致使應該6點啓動的計算3點數據的任務到7點才被提交執行，而計算4點數據的任務跑了兩次,幫忙排查下這個問題。"數據庫

2、那麼問題來了

從上述架構圖咱們知道，MasterServer進行任務的生成，放至Task Queue中，WorkerServer從Task Queue中消費任務進行執行。其次，EasyScheduler有一配置特性，若是當前結點CPU或者內存達到了80%以上，則不會進行新的任務的調度和執行。bash

綜合上述二者，大概猜想到了是master結點CPU負載太高致使的.定位步驟以下:markdown

經過公司的機器監控平臺of-dashboard查看機器的CPU、內存最近一天使用狀況

發現早上5點半開始到7點之間CPU負載呈現以80%爲中心的正態分佈，推斷當時的確是觸發了master結點的保護機制架構

查看master結點escheduler-master-xxx.log，觀察早上06:00~07:00這段時間的日誌

發現6點到7點這段時間一直處於80%高負載狀態，持續打印 [WARN] 2019-10-22 06:01:41.344 cn.escheduler.common.utils.OSUtils:[290] - load or availablePhysicalMemorySize(G) is too high, it's availablePhysicalMemorySize(G):200.01,loadAvg:23.3 信息，徹底確認是由於高負載致使。優化

可是高負載緣由是什麼呢？實際上是由於咱們混部了一些移動端採集任務在master結點上致使的（本意是處於充分利用機器）spa

從escheduler數據庫中查詢今日任務完成時間爲6:00到7:18之間的任務實例信息

得出有三項數據計算任務均爲高負載，且耗時跨度均爲2~3小時，提取出該三項任務所屬項目以及工做流定義信息，反饋給暴躁君，並讓其進行任務優化或者時間段分攤負載以保證小時計算任務正常執行。日誌

3、總結

問題定位都是有套路和步驟的，制定好troubleshooting的步驟，循序漸進能夠事半功倍code
EasyScheduler的自我保護機制是可配置的，只需在install.sh配置文件中配置以下兩個參數便可orm

# master最大cpu平均負載,用來判斷master是否還有執行能力
masterMaxCpuLoadAvg="10"

# master預留內存,用來判斷master是否還有執行能力
masterReservedMemory="1"
複製代碼

你瞭解了EasyScheduler的套路了嗎？