公平调度计算方法

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中的默认算法。