hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tsuyoshi OZAWA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MAPREDUCE-6118) Uber-mode decision does not consider -Xmx
Date Fri, 03 Oct 2014 04:31:34 GMT

    [ 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)

Mime
View raw message