yarn 容器内存溢出导致通nodemanager其它节点task finished

转载

墨韵流香 2024-10-18 11:43:32

容器放置约束

目前的约束是硬限制，如果不满足，则容器请求会被pending或者rejected。

我们用allocation这个概念指代资源的一个单位，即一个容器。

如果需要开启放置约束，我们需要修改conf/yarn-site.xml的如下配置：

yarn.resoucemanager.placement-constraints.handler：指定哪个处理器用于处理PlacementConstrains，可以使用的有：placement-processor,scheduler,disabled。

placement-processor:如果使用放置处理器，则被认为是调度器被调用前的一个前置操作。一旦放置被决定后，调度器被调起去执行真正的分配。这个处理器的好处是支持各种约束（affinity, anti-affinity, cardinality）。因为独立于调度器，所以它可以被多个调度器调用。

scheduler: 直接使用调度器作为处理器，目前，只有容量调度器支持SchedulingRequests。支持反亲和性约束。is that it follows the same ordering rules for queues (sorted by utilization, priority), apps (sorted by FIFO/fairness/priority) and tasks within the same app (priority) that are enforced by the existing main scheduler。

disabled:如果使用了SchedulingRequest，则会被拒绝。

placement-processor支持分为更广泛的约束和一次申请多个容器。然而，如果应用优先级对于用户很重要，或者使用了容量调度器，则应该使用scheduler。

使用分布式shell实验放置约束。

$ yarn org.apache.hadoop.yarn.applications.distributedshell.Client -jar share/hadoop/yarn/hadoop-yarn-applications-distributedshell-3.1.1.jar -shell_command sleep -shell_args 10 -placement_spec PlacementSpec

PlacementSpec         => "" | KeyVal;PlacementSpec
KeyVal                => SourceTag=ConstraintExpr
SourceTag             => String
ConstraintExpr        => NumContainers | NumContainers, Constraint
Constraint            => SingleConstraint | CompositeConstraint
SingleConstraint      => "IN",Scope,TargetTag | "NOTIN",Scope,TargetTag | "CARDINALITY",Scope,TargetTag,MinCard,MaxCard
CompositeConstraint   => AND(ConstraintList) | OR(ConstraintList)
ConstraintList        => Constraint | Constraint:ConstraintList
NumContainers         => int
Scope                 => "NODE" | "RACK"
TargetTag             => String
MinCard               => int
MaxCard               => int

如果-num-containers和-placement-spec被组合使用，则former被忽略。

例如：

zk=3,NOTIN,NODE,zk:hbase=5,IN,RACK,zk:spark=7,CARDINALITY,NODE,hbase,1,3

zk=5,AND(IN,RACK,hbase:NOTIN,NODE,zk)

定义放置约束。

Allocation tags

分配标识是一个字符串标识，可以关联一组容器。我们不使用ResourceRequest对象去定义分配标识，使用SchedulilngRequest对象。SchedulilngRequest跟ResourceRequest很像，但是更好的分离了数量，分配大小，优先级，执行类型等，并且约束自述这些分配应该如何被放置（资源名称，局部松弛）。应用可以使用ResourceRequest对象，但是为了去定义分配标识和约束，需要使用SchedulingRequest对象。在一个单个分配请求中，应用使用这两种中的任意一种，而不是都使用。

Allocation tags namespace

我们使用分配标识命名空间去指定分配标识可以引用的应用范围。

我们当前支持下列命名空间：

SELF：默认命令空间，tag引用当前应用的容器。

NOT_SELF：tag引用不属于当前应用的容器。

ALL：tag引用任意容器。

APP_ID：tag引用指定app_id的应用的容器。

APP_TAG：tag引用指定tag的应用的容器。

默认ns是SELF，用于intra-app约束，剩余的ns用于inter-app约束。如果不指定ns，则使用SELF。

上面的例子使用命名空间的写法如下：

zk=3,NOTIN,NODE,not-self/zk:hbase=5,IN,RACK,all/zk:spark=7,CARDINALITY,NODE,app-id/appID_0023/hbase,1,3

node labels, node attributes, allocation tags之间的不同。