当前位置 —论文—写论文— 范文

关于节点方面论文范文参考文献,与云计算文参考文献教师,云计算文参考文献培训相关论文答辩开场白

本论文是一篇关于节点方面论文答辩开场白,关于云计算文参考文献教师,云计算文参考文献培训相关学年毕业论文范文。免费优秀的关于节点及计算机应用及算法方面论文范文资料,适合节点论文写作的大学硕士及本科毕业论文开题报告范文和学术职称论文参考文献下载。

eFirst(ARF),AvgReduceSecond(ARS),AvgReduceThird(ART).当TaskTracker启动一个新任务时,如果该任务为Map任务,则将AMF和AMS作为Map任务两阶段耗用时间比例的数据,如果该任务为Reduce型任务,则将ARF,ARS,ART作为Reduce任务三个阶段耗用时间比例的数据.获得Map任务和Reduce任务各阶段时间比例的流程如图3所示.

在计算任务的当前进度时,设任务总数为J,任务当前所处阶段为第I阶段,任务当前阶段所需处理的数据条数为M,已经处理完成的数据条数为N.任务的进度为Progress,当前阶段已经完成的进度为SProgress,J个任务的平均进度为AvgProgress.则阶段内进度如公式(3)所示:

(3)

Map任务的两阶段计算进度方法如公式(4),(5)所示.

本篇论文转载于:http://www.sxsky.net/xie/07011872.html

当I等于0时,则

Progress等于AMF*SProgress(4)

当I等于1时,则

Progress等于AMF+AMS*SProgress(5)

Reduce任务的三阶段计算进度方法如公式(6),(7),(8)所示.

当I等于0时,则

Progress等于ARF*SProgress(6)

当I等于1时,则

Progress等于ARF+ARS*SProgress(7)

当I等于2时,则

Progress等于ARF+ARS+ART*SProgress(8)

J个任务的平均进度为:

(9)

这里仍然Hadoop原有的LATE算法计算任务执行速率的方式,且Map任务和Reduce任务的执行速率相同,即:

PRM等于PRR等于progress/T(10)

在式(11)中,ProgressRateMap(PRM)为单位时间内Map任务的进度增长,ProgressRateReduce(PRR)为单位时间内Reduce任务的进度增长,T为从任务开始执行到当前时间所耗用的时间.AvgProgressRate(APR)是同类任务执行的平均速率,将APR分为Map任务的AvgProgressRateMap(APRM)和Reduce任务的AvgProgressRateReduce(APRR),Map和Reduce任务的数量分别记作CountMap(CM)和CountReduce(CR).这样,可以得到Map任务的平均速率如式(11

关于节点方面论文范文参考文献)所示:

(11)

Reduce任务的平均速率如式(12)所示:

(12)

定义一个常数SlowTaskThreshold(STT)作为判定一个任务是否为慢任务的阈值,在本文中,若Map任务的速率满足:

PRM<,(1-STT)*APRM(13)

则判定该Map任务为Map慢的任务,若Reduce任务的速率满足:

PRR<,(1-STT)*APRR(14)

则判定该Reduce任务为Reduce慢的任务.

2.2任务的剩余时间估计算法

判定一个任务是否为落后任务并且为之启动备份任务需要满足以下几个条件:(1)系统中正在运行的备份任务数量小于阈值SpeculativeCap,(2)该任务已经执行超过60s,(3)该任务被判定为Map慢任务或者Reduce慢任务,(4)该任务在所属的Map慢任务或者Reduce慢任务中,是剩余时间最长的.由于Map慢的任务和Reduce慢的任务是不同类型的,所以落后任务也需被区分为Map落后任务和Reduce落后任务.寻找出Map落后任务和Reduce落后任务之后,将这些落后任务分别在执行Map任务快的TaskTracker和执行Reduce任务快的TaskTracker上启动备份任务,只要原任务和副本中的某一个完成,则该任务即为"成功"状态,并"杀死"另一个任务.

通过式(15)计算任务的剩余时间TimeToEnd(TTE).

(15)

图4落后任务判定算法

TaskTracker在执行任务的过程中,通过周期性的向JobTracker发送心跳通信,将当前任务的Progress,ProgressRate和任务名称以及经计算得到的TimeToEnd发送给JobTracker.由JobTracker按照剩余时间排序,对Map任务和Reduce任务分别维护一个队列:QueueSlowMap,QueueSlowReduce,这两个队列中的任务都是正在运行的任务.每次有TaskTracker请求新任务时,如果该TaskTracker请求的是Map任务,同时不存在未执行的Map任务,并且系统当前的已经启动且正在运行的备份任务数量小于SpeculativeCap,那么就在队列QueueSlowMap中选取剩余时间最长的Map任务,并判断其是否为慢任务,如果是,就为之启动备份任务,否则即忽略这个TaskTracker的请求.如果该TaskTracker请求的是Reduce任务,同时不存在未执行的Reduce任务,并且系统当前的已经启动且正在运行的备份任务数量小于SpeculativeCap,那么就在队列QueueSlowReduce中选取剩余时间最长的Reduce任务,并判断其是否为慢任务,如果是,就为之启动备份任务,否则即忽略这个TaskTracker的请求,落后任务判定流程如图4所示.

3慢节点判定算法

在本文中,将TaskTracker分为四类,Map任务和Reduce任务都慢的TaskTracker,Map任务慢Reduce任务快的TaskTracker,Map任务快Reduce任务慢的TaskTracker,Map任务和Reduce任务都快的TaskTracker.由于每一个TaskTracker仅存在于一个节点上,所以找到慢的TaskTracker也即找到了执行Map任务慢或者执行Reduce任务慢的节点.由于在实际系统中存在着异构性,所以每个节点所掌握的资源质量和数量都是不同的,因此不同节点执行Map任务和Reduce任务的速率也不同,那么可能存在某个节点执行Map任务很慢但执行Reduce任务却很快,也可能存在相对的情况,某个节点执行Reduce任务很慢但是执行Map任务很快[9,10].所以,设计中将LATE算法中的慢TaskTracker区分为执行Map任务慢的TaskTracker和执行Reduce任务慢的TaskTracker这种思想是很有必要的.

本文假设系统中的TaskTracker总数为N,执行Map任务慢的TaskTracker和Reduce任务慢的TaskTracker的判定参数为STT.系统中的TaskTracker总数量为N,某个TaskTracker上正在运行的Map任务数量为CM,Reduce任务的数量为CR,在每个TaskTracker上计算得出该TaskTracker上的Map任务执行速率TTProgrseeRateMap(TTPRM)和Reduce任务执行速率TTProgrseeRateReduce(TTPRR),则该TaskTracker上的Map任务的平均执行速率为:

(16)

该TaskTracker上的Reduce任务的平均执行速率为:

(17)

系统中所有TaskTracker上的Map任务执行平均速率为:

(18)

系统中TaskTracker上的Reduce任务执行平均速率为:

(19)

判断系统中某个TaskTracker是否为执行Map任务慢的TaskTracker时,如若满足如下条件:

TTPRM<,(1-STT)*AvgTTPRM(20)

则判定此TaskTracker为执行Map任务慢的TaskTracker.

判断系统中某个TaskTracker是否为执行Reduce任务慢的TaskTracker时,如若满足如下条件:

TTPRR<,(1-STT)*AvgTTPRR(21)