本文主要記錄了fair排程器drf排程政策作業不執行問題的解決過程，重點介紹了調查方法和調查過程細節，希望對大家了解fair排程器有所幫助
。
除本人
知乎專欄外，轉載請聯系我。
一．問題背景
yarn的排程器有capacity和fair兩種，之間的差別可以自行谷歌。fair排程器（附錄1）是企業級hadoop使用者常用的資源池類型，該排程器預設的隊列内部排程政策（SchudelingPolicy）是fair，即配置設定資源時隻考慮記憶體限制。
對一個跨部門多個團隊共同使用的大叢集來說，如果存在cpu密集型作業，不進行cpu控制肯定會影響其他作業的運作。想要在配置設定資源時同時計算記憶體和cpu限制，需要指定隊列的排程政策為drf，即DominantResourceFainessPolicy（附錄2）。一般配合cgroup使用，控制容器實際的cpu資源（附錄3）。
使用drf時遇到一個問題，配置非常簡單的一個fair-scheduler示例，但作業送出後不配置設定資源。
配置如下：
運作wordcount卡住
将排程政策由drf改成fair或不設定（預設還是fair），作業運作正常
下面詳細分析調查過程，
不關心分析過程的可直接看五.結論章節。二.發現表象原因
1. 查fair官網文檔，沒發現有什麼問題。
2. 搜谷歌，沒找到類似問題。搜github hadoop的issue，也沒找到類似問題。
3. 看了官網文檔和其他技術網站的各種示例，靈光一閃，将queue的name從default換成root，作業運作正常了。難道是不能叫default？
4. 嘗試queue的name為“defaul”等等，作業都正常。就是default不行。但排程政策換回fair後，default可以。
5. 搜hadoop源碼，沒找到有類似對default做特殊業務處理的地方。
6. 測試叢集用的emr-hadoop 2.7.2版本，是hadoop定制版。換成apache原生的hadoop 2.7.2，queue名字為default作業也不運作。說明原生hadoop也有同樣問題。
那麼為什麼隊列叫default作業就不運作呢？ 三.深入調查的方法通過加列印日志的方式定位問題。
1. 下載下傳hadoop源碼（附錄四），fair排程器的源碼在./hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager子項目下，org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair包裡。
2. 參考一些源碼分析的文章（附錄五，六，七）看fair排程器的源碼，在合适的地方加列印日志。
3. 對子項目打包，執行mvn package –DskipTests，target目錄下生成hadoop-yarn-server-resourcemanager-2.7.2.jar。
4. 上傳到伺服器，代替hadoop目錄下的share/hadoop/yarn/hadoop-yarn-server-resourcemanager-2.7.2.jar。
5. 重新開機resourcemanager。
6. 修改fair-scheduler的配置，送出作業，檢視resourceManager的日志輸出。
四.調查過程
4.1作業為什麼不執行
FSLeafQueue類的updateDemand()方法會重新整理子隊列的資源請求，加列印如圖，檢視隊列實時資源，隊列名，排程政策，最大資源，作業資訊等。
看日志發現，
1. 不管配置檔案的隊列名是什麼，作業都送出給了root.default這個隊列。說明作業預設都是送出到這個隊列。
2. 該隊列的實時資源fairShare隻有記憶體，vcores一直是0.
3. 當配置檔案顯式配置了default隊列排程政策為drf時，root.default隊列的排程政策為drf。作業申請AM要一個vcores資源，沒資源一直等待。
4. 當配置檔案沒顯式配置default時，root.default隊列的排程政策為預設的fair，作業申請AM隻計算記憶體資源，成功配置設定資源。
那麼隻有root.default這個隊列會vcores一直為0嗎？配置檔案設定另一個隊列test，排程政策為drf，作業送出時指定test隊列：
hadoop jar /opt/apps/ecm/service/hadoop/2.7.2-1.2.14/package/hadoop-2.7.2-1.2.14/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.7.2.jar
wordcount -D mapreduce.job.queuename=test /apps/tez-0.9.1/NOTICE count10
發現依然vcores為0，作業一直等待。
作業不執行的原因确定了，是隊列一直沒有vcores資源。drf排程政策，am需要一個vcores資源，沒有就一直等待資源。那為什麼所有隊列都沒有vcores資源呢？4.2.隊列為什麼沒有vcores資源
繼續加列印，FairScheduler類的update（）方法會更新各隊列的資源配置設定，加列印檢視root根隊列的叢集資源。
ComputeFairShares類的computeShares()方法會計算隊列内部各子隊列/作業的資源配置設定，加列印。
日志看到，
root根隊列的叢集資源是有vcores的，但root.default隊列一直沒有配置設定到vcores資源！繼續加列印，FSLeafQueue類和FSParentQueue類的recomputeShares()方法是重新計算隊列内部資源的入口，加列印。
終于發現問題了，root根隊列排程政策是預設的fair，給子隊列配置設定資源時，FairSharePolicy類的computeShares()方法隻會配置設定記憶體類型的資源，是以root.default隊列隻有記憶體資源，一旦配置子隊列排程類型為drf計算vcores資源，會因為沒有vcores資源一直等待。
驗證，配置檔案配置root和default兩個隊列，排程政策都是drf。送出作業到default隊列，正常運作，日志顯示default隊列配置設定到了vcores資源。
4.3.排程器初始化細節
QueueManager類的initialize()方法，會用隊列預設屬性初始化了一個root根隊列，和一個root.default子隊列。
配置檔案裡寫的隊列名的規則是如果不是以root.開頭或就是root，就增加“root.”字首放到root根隊列下。
讀配置檔案時，如果有root隊列或default/root.default隊列，會覆寫這兩個隊列的預設配置。
五．結論
如果想用drf排程政策計算vcores資源，那麼必須從root根隊列遞歸到葉子隊列，顯式配置所有隊列排程政策都為drf。如果父隊列沒配置用了預設fair，那麼隻會給子隊列配置設定記憶體資源，子隊列用drf排程政策作業就都會沒資源卡住。
六．Fair排程器源碼詳解
待補充七.附錄
1.
fair排程器官方文檔2.
yarn公平排程drf算法3.
yarn的cpu資源隔離4.
hadoop源碼5.
fair排程器的資源配置設定機制6.
fair排程器源碼分析7.
計算fairshare源碼分析