[
https://issues.apache.org/jira/browse/MAPREDUCE-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157669#comment-14157669
]
Tsuyoshi OZAWA commented on MAPREDUCE-6118:
-------------------------------------------
One another way we can go is to have fraction approach like Tez: if the
fraction is 0.8, Xmx will be 0.8 * yarn.app.mapreduce.am.resource.mb and
configure yarn.app.mapreduce.am.command-opts as
Xmx(0.8*yarn.app.mapreduce.am.resource.mb) in addition to user-defined
yarn.app.mapreduce.am.command-opts.
> Uber-mode decision does not consider -Xmx
> -----------------------------------------
>
> Key: MAPREDUCE-6118
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6118
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Reporter: Maysam Yabandeh
> Priority: Minor
>
> Current the decision on using uber-mode is based on the mapper container size
> and the AM container size. However the actual memory at AM is limited by -Xmx
> options passed via yarn.app.mapreduce.am.command-opts.
> For example: AM memory: 4G, yarn.app.mapreduce.am.command-opts=-Xmx2048GB,
> mapper memory: 3GB. Here the uber job could face OOM whereas a non-uber
> execution would not.
> We faced this problem recently and forced to disable uber-mode to circumvent
> the problem. One idea, although a bit ugly, is to parse jvm opts, extract
> Xmx, and take it into account for uber-mode decision.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
