公平調度計算方法

A. hadoop調度演算法中怎麼判斷哪個是快節點，哪個是慢節點

Hadoop集群中有三種作業調度演算法，分別為FIFO，公平調度演算法和計算能力調度演算法
先來先服務（FIFO）
FIFO比較簡單，hadoop中只有一個作業隊列，被提交的作業按照先後順序在作業隊列中排隊，新來的作業插入到隊尾。一個作業運行完後，總是從隊首取下一個作業運行。這種調度策略的優點是簡單、易於實現，同時也減輕了jobtracker的負擔。但是它的缺點也是顯然的，它對所有的作業都一視同仁，沒有考慮到作業的緊迫程度，另外對小作業的運行不利。
公平調度策略
這種策略在系統中配置了任務槽，一個任務槽可以運行一個task任務，這些任務就是一個大的作業被切分後的小作業。當一個用戶提交多個作業時，每個作業可以分配到一定的任務槽以執行task任務（這里的任務槽可以理解為可以運行一個map任務或rece任務）。如果把整個hadoop集群作業調度跟操作系統的作業調度相比，第一種FIFO就相當於操作系統中早期的單道批處理系統，系統中每個時刻只有一道作業在運行，而公平調度相當於多道批處理系統，它實現了同一個時刻多道作業同時運行。由於linux是多用戶的，若有多個用戶同時提交多個作業會怎樣？在這種策略中給每個用戶分配一個作業池，然後給每個作業池設置一個最小共享槽個數，什麼是最小共享槽個數呢？先要理解一個最小什麼意思，最小是指只要這個作業池需要，調度器應該確保能夠滿足這個作業池的最小任務槽數的需求，但是如何才能確保在它需要的時候就有空的任務槽，一種方法是固定分配一定數量的槽給作業池不動，這個數量至少是最小任務槽值，這樣只要在作業池需要的時候就分配給它就行了，但是這樣在這個作業池沒有用到這么多任務槽的時候會造成浪費，這種策略實際上是這樣做的，當作業池的需求沒有達到最小任務槽數時，名義上是自己的剩餘的任務槽會被分給其他有需要的作業池，當一個作業池需要申請任務槽的時候若系統中沒有了，這時候不會去搶占別人的（也不知道搶誰的啊），只要當前一個空的任務槽釋放會被立即分配給這個作業池。
在一個用戶的作業池內，多個作業如何分配槽這個可以自行選擇了如FIFO。所以這種調度策略分為兩級：
第一級，在池間分配槽，在多用戶的情況下，每個用戶分配一個作業池。
第二級，在作業池內，每個用戶可以使用不同的調度策略。
計算能力調度
計算能力調度和公平調度有點類似，公平調度策略是以作業池為單位分配任務槽，而計算能力調度是以隊列為單位分配tasktracker（集群中一個節點），這種調度策略配置了多個隊列，每個隊列配置了最小額度的tasktracker數量，同公平調度策略類似，當一個隊列有空閑的tasktracker時，調度器會將空閑的分配給其他的隊列，當有空閑的tasktracker時，由於這時候可能有多個隊列沒有得到最小額度的tasktracker而又在申請新的，空閑的tasktracker會被優先分配到最飢餓的隊列中去，如何衡量飢餓程度呢？可以通過計算隊列中正在運行的任務數與其分得的計算資源之間的比值是否最低來判斷的，越低說明飢餓程度越高。
計算能力調度策略是以隊列的方式組織作業的，所以一個用戶的作業可能在多個隊列中，如果不對用戶做一定的限制，很可能出現在多個用戶之間出現嚴重不公平的現象。所以在選中新作業運行時候，還需要考慮作業所屬的用戶是否超過了資源的限制，如果超過，作業不會被選中。
對於在同一個隊列中，這種策略使用的是基於優先順序的FIFO策略，但是不會搶占。

B. Xen虛擬機的Credit調度演算法復雜度如何計算

Xen主要有兩種虛擬機調度演算法：SEDF調度演算法和Credit調度演算法。Credit調度演算法是一種多處理器負載均衡（Global Load Balancing）的調度演算法。時間復雜度一定跟虛擬機個數以及虛擬機的虛擬CPU的數量有關
介紹一下Credit演算法：
在Credit演算法中虛擬機監控器VMM為每個虛擬機分配credit值，並根據credit值公平調度每個虛擬操作系統。

VMM根據客戶操作系統的需求分配其CPU資源，客戶操作系統的虛擬CPU的優先順序狀態分別為BOOST、UNDER和OVER。虛擬CPU接收到一個事件後被喚醒，此時虛擬CPU的優先順序被設置為BOOST；UNDER表示虛擬CPU的credit值存在剩餘，急需獲得物理CPU的使用權；OVER表示虛擬CPU的credit值已用完。

當進行虛擬機調度時，虛擬機監控器VMM根據虛擬CPU所處的優先順序狀態進行虛擬CPU的調度，UNDER狀態虛擬CPU的優先順序高於OVER狀態虛擬CPU的優先順序，優先順序高的虛擬CPU會優先調度而獲得物理CPU資源的使用權，只有當所有調度隊列中沒有可調度的UNDER狀態虛擬CPU時，VMM才會調度到OVER狀態的虛擬CPU。處於相同狀態的虛擬CPU按照先進先出的方式運行。

C. 調度的其它相關

通信調度
在通信業務中，頻譜資源和功率資源都是有限的，但小區里用戶數量和業務量是不同的，系統不能只顧慮一部分用戶，它要對資源進行合理的分配，以使系統中的用戶得以正常良好的通信。這種分配的方法或者策略，即為調度演算法或者調度技術。
最大載干比和輪詢調度分別是以吞吐量最大化和公平性最優為准則的兩種調度極端。實際的調度演算法都介於這兩者之間，最常用的就是比例公平調度。比例公平調度既考慮了用戶間的公平性（讓所有用戶都得到服務），也考慮了系統吞吐量優化（盡可能地提高頻譜效率，解決成本）。
綜上所述，通過調度器在適當的時刻（某一特定傳輸時間間隔）運用適當的方法（如PR（Premium Rate Preannouncement，在呼叫接通前提示用戶資費信息）、MAX C/I、PF調度演算法）為適當的用戶（系統中的某些用戶）分配適當的資源（如PRB（Physical Resource Block，物理資源塊）、HARQ（Hybrid Automatic Repeat Request，混合自動重傳請求）、PDCCH CCE（Control Channel Element，控制信道單元）、功率等）以使系統中的用戶得以正常良好的通信，就是通信業務中的調度技術。

D. linux進程調度的三種策略是什麼

linux內核的三種主要調度策略：
1，SCHED_OTHER 分時調度策略，
2，SCHED_FIFO實時調度策略，先到先服務
3，SCHED_RR實時調度策略，時間片輪轉

實時進程將得到優先調用，實時進程根據實時優先順序決定調度權值。分時進程則通過nice和counter值決定權值，nice越小，counter越大，被調度的概率越大，也就是曾經使用了cpu最少的進程將會得到優先調度。

SHCED_RR和SCHED_FIFO的不同：
當採用SHCED_RR策略的進程的時間片用完，系統將重新分配時間片，並置於就緒隊列尾。放在隊列尾保證了所有具有相同優先順序的RR任務的調度公平。
SCHED_FIFO一旦佔用cpu則一直運行。一直運行直到有更高優先順序任務到達或自己放棄。
如果有相同優先順序的實時進程（根據優先順序計算的調度權值是一樣的）已經准備好，FIFO時必須等待該進程主動放棄後才可以運行這個優先順序相同的任務。而RR可以讓每個任務都執行一段時間。

相同點：
RR和FIFO都只用於實時任務。
創建時優先順序大於0(1-99)。
按照可搶占優先順序調度演算法進行。
就緒態的實時任務立即搶占非實時任務。

所有任務都採用linux分時調度策略時：
1，創建任務指定採用分時調度策略，並指定優先順序nice值(-20~19)。
2，將根據每個任務的nice值確定在cpu上的執行時間(counter)。
3，如果沒有等待資源，則將該任務加入到就緒隊列中。
4，調度程序遍歷就緒隊列中的任務，通過對每個任務動態優先順序的計算權值(counter+20-nice)結果，選擇計算結果最大的一個去運行，當這個時間片用完後(counter減至0)或者主動放棄cpu時，該任務將被放在就緒隊列末尾(時間片用完)或等待隊列(因等待資源而放棄cpu)中。
5，此時調度程序重復上面計算過程，轉到第4步。
6，當調度程序發現所有就緒任務計算所得的權值都為不大於0時，重復第2步。

所有任務都採用FIFO時：
1，創建進程時指定採用FIFO，並設置實時優先順序rt_priority(1-99)。
2，如果沒有等待資源，則將該任務加入到就緒隊列中。
3，調度程序遍歷就緒隊列，根據實時優先順序計算調度權值(1000+rt_priority),選擇權值最高的任務使用cpu，該FIFO任務將一直佔有cpu直到有優先順序更高的任務就緒(即使優先順序相同也不行)或者主動放棄(等待資源)。
4，調度程序發現有優先順序更高的任務到達(高優先順序任務可能被中斷或定時器任務喚醒，再或被當前運行的任務喚醒，等等)，則調度程序立即在當前任務堆棧中保存當前cpu寄存器的所有數據，重新從高優先順序任務的堆棧中載入寄存器數據到cpu，此時高優先順序的任務開始運行。重復第3步。
5，如果當前任務因等待資源而主動放棄cpu使用權，則該任務將從就緒隊列中刪除，加入等待隊列，此時重復第3步。

所有任務都採用RR調度策略時：
1，創建任務時指定調度參數為RR，並設置任務的實時優先順序和nice值(nice值將會轉換為該任務的時間片的長度)。
2，如果沒有等待資源，則將該任務加入到就緒隊列中。
3，調度程序遍歷就緒隊列，根據實時優先順序計算調度權值(1000+rt_priority),選擇權值最高的任務使用cpu。
4，如果就緒隊列中的RR任務時間片為0，則會根據nice值設置該任務的時間片，同時將該任務放入就緒隊列的末尾。重復步驟3。
5，當前任務由於等待資源而主動退出cpu，則其加入等待隊列中。重復步驟3。

系統中既有分時調度，又有時間片輪轉調度和先進先出調度：
1，RR調度和FIFO調度的進程屬於實時進程，以分時調度的進程是非實時進程。
2，當實時進程准備就緒後，如果當前cpu正在運行非實時進程，則實時進程立即搶占非實時進程。
3，RR進程和FIFO進程都採用實時優先順序做為調度的權值標准，RR是FIFO的一個延伸。FIFO時，如果兩個進程的優先順序一樣，則這兩個優先順序一樣的進程具體執行哪一個是由其在隊列中的未知決定的，這樣導致一些不公正性(優先順序是一樣的，為什麼要讓你一直運行?),如果將兩個優先順序一樣的任務的調度策略都設為RR,則保證了這兩個任務可以循環執行，保證了公平。

Ingo Molnar-實時補丁
為了能並入主流內核，Ingo Molnar的實時補丁也採用了非常靈活的策略，它支持四種搶占模式：
1．No Forced Preemption (Server)，這種模式等同於沒有使能搶占選項的標准內核，主要適用於科學計算等伺服器環境。
2．Voluntary Kernel Preemption (Desktop)，這種模式使能了自願搶占，但仍然失效搶占內核選項，它通過增加搶占點縮減了搶占延遲，因此適用於一些需要較好的響應性的環境，如桌面環境，當然這種好的響應性是以犧牲一些吞吐率為代價的。
3．Preemptible Kernel (Low-Latency Desktop)，這種模式既包含了自願搶占，又使能了可搶占內核選項，因此有很好的響應延遲，實際上在一定程度上已經達到了軟實時性。它主要適用於桌面和一些嵌入式系統，但是吞吐率比模式2更低。
4．Complete Preemption (Real-Time)，這種模式使能了所有實時功能，因此完全能夠滿足軟實時需求，它適用於延遲要求為100微秒或稍低的實時系統。
實現實時是以犧牲系統的吞吐率為代價的，因此實時性越好，系統吞吐率就越低。

E. 怎麼優化hadoop任務調度演算法

首先介紹了Hadoop平台下作業的分布式運行機制，然後對Hadoop平台自帶的4種任務調度器做分析和比較，最後在分析JobTracker類文件的基礎上指出了創建自定義任務調度器所需完成的工作。
首先Hadoop集群式基於單伺服器的，只有一個伺服器節點負責調度整個集群的作業運行，主要的具體工作是切分大數據量的作業，指定哪些Worker節點做Map工作、哪些Worker節點做Rece工作、與Worker節點通信並接受其心跳信號、作為用戶的訪問入口等等。其次，集群中的每個Worker節點相當於一個器官，運行著主節點所指派的具體作業。這些節點會被分為兩種類型，一種是接收分塊之後的作業並做映射工作。另一種是負責把前面所做的映射工作按照約定的規則做一個統計。
Task－Tracker通過運行一個簡單循環來定期地發送心跳信號（heartbeat）給JobTracker．這個心跳信號會把TaskTracker是否還在存活告知JobTracker，TaskTracker通過信號指明自己是否已經准備
好運行新的任務．一旦TaskTracker已經准備好接受任務，JobTracker就會從作業優先順序表中選定一個作業並分配下去．至於到底是執行Map任務還是Rece任務，是由TaskTracker的任務槽所決定的．默認的任務調度器在處理Rece任務之前，會優先填滿空閑的Map任務槽．因此，如果TaskTracker滿足存在至少一個空閑任務槽時，JobTracker會為它分配Map任務，否則為它選擇一個Rece任務．TaskTracker在運行任務的時候，第一步是從共享文件系統中把作業的JAR文件復制過來，從而實現任務文件的本地化．第二步是TaskTracker為任務新建一個本地文件夾並把作業文件解壓在此目錄中．第三步是由Task－Tracker新建一個TaskRunner實例來運行該任務．
Hadoop平台默認的調度方案就是JobQueueTaskScheler，這是一種按照任務到來的時間先後順序而執行的調度策略．這種方式比較簡單，JobTracker作為主控節點，僅僅是依照作業到來的先後順序而選擇將要執行的作業．當然，這有一定的缺陷，由於Hadoop平台是默認將作業運行在整個集群上的，那麼如果一個耗時非常大的作業進入執行期，將會導致其餘大量作業長時間得不到運行．這種長時間運行的優先順序別並不高的作業帶來了嚴重的作業阻塞，使得整個平台的運行效率處在較低的水平．Hadoop平台對這種FIFO（FirstINAndFirstOut）機制所給出的解決辦法是調用SetJobPriority（）方法，通過設置作業的權重級別來做平衡調度．
FairScheler是一種「公平」調度器，它的目標是讓每個用戶能夠公平地共享Hadoop集群計算能力．當只有一個作業運行的時候，它會得到整個集群的資源．隨著提交到作業表中作業的增多，Hadoop平台會把集群中空閑出來的時間槽公平分配給每個需要執行的作業．這樣即便其中某些作業需要較長時間運行，平台仍然有能力讓那些短作業在合理時間內完成［3］．FairScheler支持資源搶占，當一個資源池在一定時段內沒有得到公平共享時，它會終止該資源池所獲得的過多的資源，同時把這些釋放的資源讓給那些資源不足的資源池．
Hadoop平台中的CapacityScheler是由Yahoo貢獻的，在調度器上，設置了三種粒度的對象：queue，job，task．在該策略下，平台可以有多個作業隊列，每個作業隊列經提交後，都會獲得一定數量的TaskTracker資源．具體調度流程如下．
（1）選擇queue，根據資源庫的使用情況從小到大排序，直到找到一個合適的job．
（2）選擇job，在當前所選定的queue中，按照作業提交的時間先後以及作業的權重優先順序別進行排序，選擇合適的job．當然，在job選擇時還需要考慮所選作業是否超出目前現有的資源上限，以及資源池中的內存是否夠該job的task用等因素．
（3）選擇task，根據本地節點的資源使用情況來選擇合適的task．
雖然Hadoop平台自帶了幾種調度器，但是上述3種調度方案很難滿足公司復雜的應用需求．因此作為平台的個性化使用者，往往需要開發自己的調度器．Hadoop的調度器是在JobTracker中載入和調用的，因此開發一個自定義的調度器就必須搞清楚JobTracker類文件的內部機制．作為Hadoop平台的核心組件，JobTracker監控著整個集群的作業運行情況並對資源進行管理調度．每個Task－Tracker每隔3s通過heartbeat向JobTracker匯報自己管理的機器的一些基本信息，包括內存使用量、內存的剩餘量以及空閑的slot數目等等［5］．一
旦JobTracker發現了空閑slot，便會調用調度器中的AssignTask方法為該TaskTracker分配task。

F. 有一個具有兩道作業的批處理系統，作業調度採用短作業優先調度演算法，進程調度採用以優先數為基礎的搶占式

本題中的系統是兩道作業系統，因此每次只能有兩個作業進入系統，作業調度采

用短作業優先演算法，只有調度進入系統的進程方能參與進程調度；進程調度採用

基於優先數的搶占式調度演算法，高優先順序的進程可以搶占系統處理機。

本題的作業和進程的推進過程如下：

10：00 A作業到達，被作業調度程序調度進入系統，被進程調度程序調度開始運行

10：20 A作業運行20分鍾，剩餘20分鍾，由於優先順序低，被進程調度程序調度處於就緒狀態

B作業到達，被作業調度程序調度進入系統，由於優先順序高，被進程調度程序調度處於開始運行狀態

10：30 A作業等待10分鍾，剩餘20分鍾，繼續等待

B作業運行10分鍾，剩餘20分鍾，繼續運行

C作業到達，等待被作業調度程序調度

10：50 A作業等待30分鍾，剩餘20分鍾，由於優先順序高，被進程調度程序調度處於開始運行狀態

B作業運行30分鍾，作業完成，結束運行

C作業等待20分鍾，由於估計運行時間較長，仍未被調入系統中運行

D作業到達，被進程調度程序調度處於就緒狀態

11：10 A作業運行40分鍾，作業完成，結束運行

C作業等待30分鍾，被作業調度程序調度進入系統，由於優先順序高，被進程調度程序調度處於開始運行狀態

D作業等待10分鍾，由於優先順序低，被進程調度程序調度處於就緒狀態

12：00 C作業運行50分鍾，作業完成，結束運行

D作業等待70分鍾，被進程調度程序調度處於開始運行狀態

12：20 D作業運行20分鍾，作業完成，結束運行

各作業周轉時間為：

作業A 70，作業B 30，作業C 90，作業D 90。

平均作業周轉時間為70分鍾。

參考1.網頁鏈接

2.網頁鏈接

略改動。

G. 深度調度概念深度調度的概念

咨詢記錄 · 回答於2021-07-17

H. 怎樣打開hadoop2的公平調度器

公平調度是一種賦予作業（job）資源的方法，它的目的是讓所有的作業隨著時間的推移，都能平均的獲取等同的共享資源。當單獨一個作業在運行時，它
將使用整個集群。當有其它作業被提交上來時，系統會將任務（task）空閑時間片（slot）賦給這些新的作業，以使得每一個作業都大概獲取到等量的
CPU時間。與Hadoop默認調度器維護一個作業隊列不同，這個特性讓小作業在合理的時間內完成的同時又不「餓」到消耗較長時間的大作業。它也是一個在
多用戶間共享集群的簡單方法。公平共享可以和作業優先權搭配使用——優先權像權重一樣用作為決定每個作業所能獲取的整體計算時間的比例。
公平調度器按資源池（pool）來組織作業，並把資源公平的分到這些資源池裡。默認情況下，每一個用戶擁有一個獨立的資源池，以使每個用戶都能
獲得一份等同的集群資源而不管他們提交了多少作業。按用戶的Unix群組或作業配置（jobconf）屬性來設置作業的資源池也是可以的。在每一個資源池
內，會使用公平共享（fairsharing）的方法在運行作業之間共享容量（capacity）。你也可以給予資源池相應的權重，以不按比例的方式共享
集群。

除了提供公平共享方法外，公平調度器允許賦給資源池保證（guaranteed）最小共享資源，這個用在確保特定用戶、群組或生產應用程序總能
獲取到足夠的資源時是很有用的。當一個資源池包含作業時，它至少能獲取到它的最小共享資源，但是當資源池不完全需要它所擁有的保證共享資源時，額外的部分
會在其它資源池間進行切分。

在常規操作中，當提交了一個新作業時，公平調度器會等待已運行作業中的任務完成以釋放時間片給新的作業。但，公平調度器也支持在可配置的超時時
間後對運行中的作業進行搶占。如果新的作業在一定時間內還獲取不到最小的共享資源，這個作業被允許去終結已運行作業中的任務以獲取運行所需要的資源。因此
搶占可以用來保證「生產」作業在指定時間內運行的同時也讓Hadoop集群能被實驗或研究作業使用。另外，作業的資源在可配置的超時時間（一般設置大於最
小共享資源超時時間）內擁有不到其公平共享資源（fair
share）的一半的時候也允許對任務進行搶占。在選擇需要結束的任務時，公平調度器會在所有作業中選擇那些最近運行起來的任務，以最小化被浪費的計算。
搶占不會導致被搶占的作業失敗，因為Hadoop作業能容忍丟失任務，這只是會讓它們的運行時間更長。

最後，公平調度器還可以限制每用戶和每資源池的並發運行作業數量。當一個用戶必須一次性提交數百個作業時，或當大量作業並發執行時，用來確保中
間數據不會塞滿集群上的磁碟空間，這是很有用的。設置作業限制會使超出限制的作業被列入調度器的隊列中進行等待，直到一些用戶/資源池的早期作業運行完
畢。系統會根據作業優先權和提交時間的排列來運行每個用戶/資源池中的作業。

安裝

要讓公平調度器能在你的Hadoop中運行，你需要把它放到CLASSPATH中。最簡單的方法就是把hadoop-*-fairscheler.jar從HADOOP_HOME/build/contrib/fairscheler拷貝到HADOOP_HOME/lib。你也可以修改HADOOP_CONF_DIR/hadoop-env.sh中的HADOOP_CLASSPATH，加入公平調度器的jar包。

你還需要在Hadoop的配置文件HADOOP_CONF_DIR/mapred-site.xml中設置下列屬性讓Hadoop使用公平調度器：

<property>

<name>mapred.jobtracker.taskScheler</name>

<value>org.apache.hadoop.mapred.FairScheler</value>

</property>

在重啟集群後，你可以通過JobTracker的web用戶界面中的http://<jobtrackerURL>/scheler檢查公平調度器是否正在運行。你應該能看到一個"job scheler administration"頁面。我們將在管理章節講述這個頁面。

如果你想從源碼中編譯公平調度器，請在你的HADOOP_HOME目錄中運行ant package。這個操作將會構建build/contrib/fair-scheler/hadoop-*-fairscheler.jar。

配置

公平調度器有兩處配置文件——演算法參數在mapred-site.xml中設置，還有一個單獨的稱為配額文件（allocation file）的XML文件，可以用來配置資源池、最小共享資源、運行作業限制和搶占超時時間。配額文件在運行時會定期被重新載入，這可以讓你修改資源池的設置而不用重啟Hadoop集群。

對於僅需要在用戶間獲取等同共享的最小化安裝，你就不需要去配置配額文件了。如果對配額文件進行了配置，你需要設置mapred-site.xml中的mapred.fairscheler.allocation.file（下面描述）參數告訴調度器怎麼去找到配額文件。

mapred-site.xml中的調度器參數

可以在mapred-site.xml中設置下面的參數來影響公平調度器的行為：

基本參數

屬性名

描述

mapred.fairscheler.allocation.file

指定一個XML文件的絕對路徑，該文件包含了每個資源池的最小共享資源、每資源池和每用戶的並發運行作業數和搶占超時時間。如果沒有設置這個屬性，這些特性將不會被使用。配額文件格式在稍後描述。

mapred.fairscheler.preemption

是否啟用搶占的布爾值屬性。默認是false。

mapred.fairscheler.poolnameproperty

指定用哪個作業配置屬性來決定作業的歸屬資源池。字元串格式，默認：user.name（即是每個用戶一個資源池）。另一個有用的值是group.name，即每個Unix群組一個資源池。一個常用的設定是使用非標準的屬性如pool.name作為資源池的名字屬性，然後通過添加下面的設定來使user.name成為默認：

<property>

<name>pool.name</name>

<value>${user.name}</value>

</property>

這樣你就可以對某些作業顯式的通過作業配置屬性來指定資源池的名字（比如，在有默認用戶資源池的情況下，傳遞 -Dpool.name=<name> 到 bin/hadoop jar）。

高級參數

屬性名

描述

mapred.fairscheler.sizebasedweight

在計算作業的公平共享權重時考慮作業大小。默認情況下，權重只基於作業的優先權。設置這個標志為true會使權重也考慮作業大小（所需任務數），但
不是線性的（權重與所需任務數的對數成比例）。這個設定讓較大作業在獲取更大的公平共享資源的同時也能提供足夠的共享資源給小作業，讓它們能迅速的完成。
布爾值，默認是false。

mapred.fairscheler.preemption.only.log

這個標志會使調度器在碰到搶占計算時僅簡單的記錄下它什麼時候想搶佔一個任務，而不會真正的搶占任務。布爾值，默認是false。這個屬性用在啟用
搶占之前做一個搶占的「dry run」是很有用的，以確保你沒把超時時間設置的過於具有侵略性。你會在Jobtracker的輸出日誌（HADOOP_LOG_DIR/hadoop-jobtracker-*.log）看到搶占日誌信息。信息跟下面的相似：

Should preempt 2 tasks for job_20090101337_0001: tasksDueToMinShare = 2, tasksDueToFairShare = 0

mapred.fairscheler.update.interval

公平共享資源計算更新間隔時間。默認的500毫秒適用於小於500個節點的集群，但較大的值可以減少更大集群的Jobtracker的負載。整數值，單位是毫秒，默認是500。

mapred.fairscheler.preemption.interval

檢查任務搶占的間隔時間。默認的15秒適用於超時時間在分鍾數量級上的。不推薦超時時間過小於這個數值，但是如果你已經設置了這樣的超時時間，你可
以使用這個值來做更多的搶占計算。然而小於5秒的值就太小了，因為它小於心跳的間隔時間了。整數值，單位是毫秒，默認是15000。

mapred.fairscheler.weightadjuster

一個擴展點，讓你指定一個類去調整運行中作業的權重。這個類應當實現WeightAdjuster介面。目前已有一個例子實現——NewJobWeightBooster，
它會在作業生命周期中的前5分鍾增加作業的權重，以使小作業能更快速的完成。要使用這個例子實現，設置weightadjuster屬性為類的全
名，org.apache.hadoop.mapred.NewJobWeightBooster。NewJobWeightBooster本身提供了兩
個參數用於設定持續時間和增長因子。

mapred.newjobweightbooster.factor，新作業權重的增長因子，默認是3。
mapred.newjobweightbooster.ration，增長持續時間，單位是毫秒。默認是300000，5分鍾。

mapred.fairscheler.loadmanager

一個擴展點，讓你指定一個類去決定一個給定TaskTracker上可以運行多少個map和rece。這個類應當實現LoadManager介面。默認使用Hadoop配置文件中的任務負載，但可以使用這個選項使負載基於如可用內存和CPU利用率。

mapred.fairscheler.taskselector

一個擴展點，讓你指定一個類去決定作業內的哪一個任務運行在給定的tracker上。這個特性可以用來改變本地化策略（比如，讓一些作業在特定機架
內）或推測（speculative）執行演算法（選擇什麼時候去執行推測任務）。默認的實現使用Hadoop的JobInProgress中的默認演算法。