[
https://issues.apache.org/jira/browse/YARN-10505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudolf Reti updated YARN-10505:
-------------------------------
Description:
Currently Fair Scheduler supports the following 3 kinds of settings:
* Single percentage (relative to parent) i.e. "X%"
* A set of percentages (relative to parent) i.e. "X% cpu, Y% memory"
* Absolute resources i.e. "X mb, Y vcores"
Please note, that the new, recommended format does not support the single
percentage mode, only the last 2, like: “vcores=X, memory-mb=Y” or “vcores=X%,
memory-mb=Y%” respectively.
Tasks to accomplish:
# It is recommended that all three formats are supported for maximum-capacity
in CS after introducing weight mode.
# Also we want to introduce the percentage modes relative to the cluster, not
the parent, i.e The property root.users.maximum-capacity will mean one of the
following things:
## Either Parent Percentage: maximum capacity relative to its parent. If it’s
set to 50, then it means that the capacity is capped with respect to the
parent. This can be covered by the current format, no change there.
## Or Cluster Percentage: maximum capacity expressed as a percentage of the
overall cluster capacity. This case is the new scenario, for example:
{{yarn.scheduler.capacity.root.users.max-capacity = c:50%}}
{{yarn.scheduler.capacity.root.users.max-capacity = c:50%, c:30%}}
was:
Currently Fair Scheduler supports the following 3 kinds of settings:
* Single percentage (relative to parent) i.e. "X%"
* A set of percentages (relative to parent) i.e. "X% cpu, Y% memory"
* Absolute resources i.e. "X mb, Y vcores"
Please note, that the new, recommended format does not support the single
percentage mode, only the last 2, like: “vcores=X, memory-mb=Y” or “vcores=X%,
memory-mb=Y%” respectively.
Tasks to accomplish:
# It is recommended that all three formats are supported for maximum-capacity
in CS after introducing weight mode.
# Also we want to introduce the percentage modes relative to the cluster, not
the parent, i.e The property root.users.maximum-capacity will mean one of the
following things:
## Either Parent Percentage: maximum capacity relative to its parent. If it’s
set to 50, then it means that the capacity is capped with respect to the parent.
## Or Cluster Percentage: maximum capacity expressed as a percentage of the
overall cluster capacity.
> Extend the maximum-capacity property to support Fair Scheduler migration
> ------------------------------------------------------------------------
>
> Key: YARN-10505
> URL: https://issues.apache.org/jira/browse/YARN-10505
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: capacity scheduler
> Reporter: Benjamin Teke
> Assignee: Benjamin Teke
> Priority: Major
>
> Currently Fair Scheduler supports the following 3 kinds of settings:
> * Single percentage (relative to parent) i.e. "X%"
> * A set of percentages (relative to parent) i.e. "X% cpu, Y% memory"
> * Absolute resources i.e. "X mb, Y vcores"
> Please note, that the new, recommended format does not support the single
> percentage mode, only the last 2, like: “vcores=X, memory-mb=Y” or
> “vcores=X%, memory-mb=Y%” respectively.
> Tasks to accomplish:
> # It is recommended that all three formats are supported for
> maximum-capacity in CS after introducing weight mode.
> # Also we want to introduce the percentage modes relative to the cluster,
> not the parent, i.e The property root.users.maximum-capacity will mean one of
> the following things:
> ## Either Parent Percentage: maximum capacity relative to its parent. If
> it’s set to 50, then it means that the capacity is capped with respect to the
> parent. This can be covered by the current format, no change there.
> ## Or Cluster Percentage: maximum capacity expressed as a percentage of the
> overall cluster capacity. This case is the new scenario, for example:
> {{yarn.scheduler.capacity.root.users.max-capacity = c:50%}}
> {{yarn.scheduler.capacity.root.users.max-capacity = c:50%, c:30%}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
