[
https://issues.apache.org/jira/browse/MAPREDUCE-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157538#comment-14157538
]
Gera Shegalov commented on MAPREDUCE-6118:
------------------------------------------
The example does not have to be a problem because mapreduce.*.memory.mb
describes the vmem requirement for the task, not the Java heap size. Task might
want only Xmx1024m out of 3gb memory for Java heap. It is reasonable to add Xmx
checks to the set of uberization constraints if Xmx is specified for both AM
and tasks.
> 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)
