[
https://issues.apache.org/jira/browse/MAPREDUCE-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157755#comment-14157755
]
Gera Shegalov commented on MAPREDUCE-6118:
------------------------------------------
[~ozawa], we actually implemented auto-Xmx earlier than Tez in MAPREDUCE-5785.
It's related but I think this JIRA is somewhat orthogonal to this: what to do
when Xmx is explicitly set by the user there is an incompatibility.
> 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)
