引數說明

mapreduce.job,reduce.slowstart.completemaps預設為0.05，在5%的map執行成功之後，就會啟動reduce作業，會導致Reduce佔用大量資源，卻無法有效利用（需要等待對應的Map執行完成），降低資源的使用效率，影響叢集的整體效能，可調至0.9。

測試跟蹤

更改了e3base07, e3base104，e3base105下的$HADOOP_HOME/etc/hadoop/mapred-site.xml檔案裡的引數為0.9。其他主機未更改，取預設值0.05。

跟蹤過程

在e3base105介面機上，使用e3base租戶跑了四個mapreduce作業:

第一個和最後一個為引數更改前後的對比。

並進行了跟蹤,待兩個作業跑完之後，執行：

hadoop job -status job_1521706963475_2653939

hadoop job -status job_1521706963475_2654088

hadoop job -status job_1521706963475_2714974

hadoop job –status job_1521706963475_2724088

其餘兩個作業也是通過該方法找到作業配置資訊。

檢視作業配置資訊：

執行hadoop fs -get /user/.../job_id_conf.xml  /localpath（從上圖中檢視具體的配置資訊hdfs位置,get到本地）

job_1521706963475_2653939:該作業啟動引數為預設的0.05。

job_1521706963475_2654088:該作業啟動引數為更改之後的0.9。

其餘兩個作業在更改後，引數也為0.9。

結論

       在第一批跟蹤過程中，只更改了介面機e3base105上的reduce啟動引數，但跟蹤發現該引數雖然在介面機e3base105上修改了，但是隻對ApplicationMaster分配到e3base105主機上的作業生效（由第一個和第二個作業可看出）。

在第二批跟蹤時，更改了e3base07和e3base104主機上的reduce啟動引數，然後對ApplicationMaster分配到這兩個節點的作業進行跟蹤，發現作業的reduce引數值都已更改為0.9。

故可得出該引數只對ApplicationMaster分配到當前主機的作業生效。

下圖為《Hadoop權威指南》中關於MapReduce過程的圖示：

個人理解：

作業在客戶端提交，ResourceManager將作業分配並在某一臺資料節點啟動container和MRAppMaster之後，才對作業進行初始化，即圖中第6步驟。在對作業初始化過程中，讀取了配置檔案。