当前位置: 首页>>hadoop 2.0之YARN>> 阅读正文

YARN/MRv2 Node Manager深入剖析—Container状态机分析

Category: hadoop 2.0之YARN View: 15,124 Author: Dong
, , , ,

  • 评论 (6)
  • 引用通告 (1)
发表评论 发起引用

  • 1楼蔡xy 回复

    Post: 2013-03-12 06:42

    但是实际上的结果其实是,即使container正常结束触发的事件仍然是killed,nodeMetrics里面killed的container数量是要多余正常完成的,如果集群运行时间稍长一点的话

    [回复]

    Dong 回复:

    嗯,你说的对,我加上。

    [回复]

    蔡xy 回复:

    我觉得这应该算个问题,既然有CONTAINER_EXITED_WITH_SUCCESS这个EventType,那就不应该触发killed,或者在containermanager细化下FINISH_CONTAINERS可以解决?不知董兄有什么想法~

    [回复]

    Dong 回复:

    是这样的,每个Container运行完后,会触发CONTAINER_EXITED_WITH_SUCCESS事件,同时清理自己占用的临时目录。当一个Application运行结束后,会向每个Container广播一个KILL_CONTAINER事件,对于运行完成的Container,不会进行任何操作(忽略该事件),但需要注意的是,(情况1)每个application(不要仅关注MapReduce ApplicationMaster)结束的准则可能不一样,比如一个用于采样的application的结束条件可能是10%的任务运行结束,一旦10%的任务运行结束,则直接向各个container发KILL_CONTAINER事件即可,这样,处于任何非运行结束状态的container将被杀掉(见本文的状态机图);(情况2)另外,
    即使一个Application运行完成了,它的某些container仍可能处于运行之中,比如为了加快计算速度,一份数据可能有两个任务同时处理(推测执行机制),当一个运行结束后,另外一个可能仍在运行中,这样,即使100%的任务运行结束了,仍可能有一些备份任务正在运行中,但这时候可让application结束;(情况3)最后,当用户杀死一个application时,可直接调用结束application的函数,这样,向所有Container广播一个KILL_CONTAINER事件即可。这都是CONTAINER_EXITED_WITH_SUCCESS事件无法解决的。
    不知我说的有道理没?

    [回复]

    蔡xy 回复:

    推测执行由AM控制,先杀attempt,再结束。我的意思不是取消kill container,而是考虑加上一个type的可行性,把正常finish和异常finish分开。因为现在的jmx里killed出现很多让人感觉很奇怪。不过也有更奇怪的一点就是launch的container总数和其他的container之和对不上,这个就是状态机的问题了,还是后一个容易解决点

    [回复]

    Dong 回复:

    推测执行是由AM控制,但AM随时可以结束,比如所有数据都处理完了,但仍有几个推测执行启动的备份任务在运行,这时候AM强制调用finishApplication()结束,也是可以正常结束的(不会有副作用,所有资源均会马上得到释放),那些备份任务会被广播的KILL_CONTAINER事件杀死。
    另外,你说的这个是metrics或者counter统计不准确,让人产生误解,你完全可通过细化对应的metrics或者counter方式解决。

    [回复]

  • 2楼Dong 回复

    Post: 2013-03-13 02:25

    推测执行是由AM控制,但AM随时可以结束,比如所有数据都处理完了,但仍有几个推测执行启动的备份任务在运行,这时候AM强制调用finishApplication()结束,也是可以正常结束的(不会有副作用,所有资源均会马上得到释放),那些备份任务会被广播的KILL_CONTAINER事件杀死。
    另外,你说的这个是metrics或者counter统计不准确,让人产生误解,你完全可通过细化对应的metrics或者counter方式解决,只要保证对外(用户)显示分开(通过metrics或者counter)即可,在Hadoop内部一些变量不准确,不影响。

    [回复]

    蔡xy 回复:

    我解决了,其实就是一个小小的时差,在stopContainer那sleep零点几秒就行了

    [回复]

    rain 回复:

    你好!我的hadoop集群每个从节点的cpu,内存都很不一样。这种情况下,请问每个机器上的container数目是怎么设定的?container是像map任务一样临时分配的,还是一个配置好了的静态资源(像hadoop1中的slot一样)。 很迷茫,跪求解答!!!

    [回复]

    Dong 回复:

    每个机器上的container数目不是固定的,每个机器只汇报cpu和内存数目,ResourceManager会将这些cpu和内存分配给每个作业。比如,一个作业的一个任务需要1 cpu和2GB内存,则把这些资源封装成一个container发回给作业,如果一个任务需要2 CPU和4GB内存,同样,它会把这些资源封装成一个container发回给作业。container是资源描述方式,是跟具体应用需求相关的。

    [回复]

  • 3楼rain 回复

    Post: 2013-04-12 06:27

    我hadoop有三各从节点,运行job 在web页面看到每个节点的container数目在运行时是固定的,分别是8,7,8.可我总的map任务有58个。按照你说的,一个map分配一个container,对不上啊。

    [回复]

    Dong 回复:

    三个节点一共多少资源,8,7,8这23个container是不是已经把所有资源都用光了。
    假设有2个节点,一共16 cpu 和32 GB内存,每个task需要1 cpu和1 GB内存,那么这个系统最多同时运行16个task,如果一个作业有160个task,那么需要运行10轮,这么简单的道理很难理解吗?

    [回复]

  • 4楼rain 回复

    Post: 2013-04-12 06:29

    container和任务哪个是因,哪个是果啊?

    [回复]

  • 5楼rain 回复

    Post: 2013-04-12 09:37

    谢谢解答!
    你说的我能理解。但我的集群从节点分别是内存4,2,2G,cpu核数分别是8,4,2,总共内存也只有8G,怎么会出现23个container?况且我的各节点资源量差别很大,分到的container数目是一样的,又怎么解释呢?

    [回复]

  • 6楼无相 回复

    Post: 2014-04-08 03:42

    您好,我想知道job各个状态的区别,以及状态转换时发生了什么,比如说finishing和finish,killjob是如何执行的,看网上资料比较少

    [回复]

发表评论