JobTracker心跳優化

馬上要開始第二階段優化了，趕快把第一階段優化內容及結果貼下。

•背景

–繁忙時段98%~100%的handler線程被BLOCK

–RPC請求堆積

•Profiling工具 （定位瓶頸）

–jstack線上環境使用

–yjp測試環境使用

優化一：避免頻繁調用加鎖方法
•500次連續jstack結果分析

–jt.getTasksToKill：15631.2%
-- tip.shouldClose 155 99.3%
    -- tip.isComplete 155 100%

•synchronized方法比non-synchronized方法慢10-15倍

•優化方法：避免調用加鎖的TIP::isComplete()

優化前，TIP::isComplete()方法佔總CPU時間達36%：

優化後：已經在圖中消失，即比例非常小。

優化二：避免比較JobID

優化前，TIP::shouldClose()方法佔到了總CPU時間的19%

•優化方案：

–TreeMap增加Comparator

–新增只比較id的tip.isComplete(tid)方法

優化後只有1%了：

優化三：降低JT::getTasksToKill()方法的時間複雜度

•優化getTasksToKill()

–優化前每次心跳遍歷TaskTracker上所有task

–優化後每次心跳遍歷TaskTracker上running task

•TaskTracker上completed tasks >> running task

優化後，心跳已經不佔主要操作：

順便說下優化三是非常給力的，舉個例子：

一個1w個map+5k個reduce的作業，當執行reduce時，map全部處於完成狀態。這段時間每次心跳都要遍歷這1w的map；

而tasktracker上running tasks的個數的最大值是個常數，也就是slots的配置。

因此這個改動是可以理解爲複雜度降低了一個數量級。

優化四：降低Scheduler::updateTaskCounts()時間複雜度

•優化Scheduler.updateTaskCounts()

–優化前：遍歷job的每個task統計runningMaps|Reduces & neededMaps|Reduces

–優化後：直接從JobInProgress中讀取上述統計值

優化總結

•根本原因：

–單點

–心跳需要持有JobTracker大鎖

•優化的關鍵是定位瓶頸

•消除一個瓶頸後，很快會出現下一個瓶頸

•終極方案：mr2 (0.23)

本次優化的最大成果是，在2000臺集羣上成功啓動了TaskTracker的oob心跳。