brumi1024 commented on a change in pull request #3894:
URL: https://github.com/apache/hadoop/pull/3894#discussion_r786230082
##########
File path:
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-site/src/site/markdown/CapacityScheduler.md
##########
@@ -151,7 +151,7 @@ Configuration
|:---- |:---- |
| `yarn.scheduler.capacity.maximum-applications` /
`yarn.scheduler.capacity.<queue-path>.maximum-applications` | Maximum number of
applications in the system which can be concurrently active both running and
pending. Limits on each queue are directly proportional to their queue
capacities and user limits. This is a hard limit and any applications submitted
when this limit is reached will be rejected. Default is 10000. This can be set
for all queues with `yarn.scheduler.capacity.maximum-applications` and can also
be overridden on a per queue basis by setting
`yarn.scheduler.capacity.<queue-path>.maximum-applications`. When this property
is not set for a specific queue path, the maximum application number is
calculated by taking all configured node labels into consideration, and
choosing the highest possible value. Integer value expected. |
| `yarn.scheduler.capacity.maximum-am-resource-percent` /
`yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent` | Maximum
percent of resources in the cluster which can be used to run application
masters - controls number of concurrent active applications. Limits on each
queue are directly proportional to their queue capacities and user limits.
Specified as a float - ie 0.5 = 50%. Default is 10%. This can be set for all
queues with `yarn.scheduler.capacity.maximum-am-resource-percent` and can also
be overridden on a per queue basis by setting
`yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent` |
-| `yarn.scheduler.capacity.max-parallel-apps` /
`yarn.scheduler.capacity.<queue-path>.max-parallel-apps` | Maximum number of
applications that can run at the same time. Unlike to `maximum-applications`,
application submissions are *not* rejected when this limit is reached. Instead
they stay in `ACCEPTED` state until they are eligible to run. This can be set
for all queues with `yarn.scheduler.capacity.max-parallel-apps` and can also be
overridden on a per queue basis by setting
`yarn.scheduler.capacity.<queue-path>.max-parallel-apps`. Integer value is
expected. By default, there is no limit. |
+| `yarn.scheduler.capacity.max-parallel-apps` /
`yarn.scheduler.capacity.<queue-path>.max-parallel-apps` | Maximum number of
applications that can run at the same time. Unlike to `maximum-applications`,
application submissions are *not* rejected when this limit is reached. Instead
they stay in `ACCEPTED` state until they are eligible to run. This can be set
for all queues with `yarn.scheduler.capacity.max-parallel-apps` and can also be
overridden on a per queue basis by setting
`yarn.scheduler.capacity.<queue-path>.max-parallel-apps`. Integer value is
expected. By default, there is no limit. The maximum parallel application limit
is an inherited property in the queue hierarchy. The limit is checked in the
queue hierarchy and the lowest value is applied as the limit. |
Review comment:
Nit: Repeating "in the queue hierarchy" so close sounds a bit off to me.
Something like this sound better to me:
...inherited property, meaning that the lowest value will be selected as the
enforced limit in every branch of the queue hierarchy.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
