Mailing-List: contact mapreduce-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mapreduce-issues@hadoop.apache.org
Date: Mon, 14 Jul 2014 17:44:05 +0000 (UTC)
From: "Rohini Palaniswamy (JIRA)" <jira@apache.org>
To: mapreduce-issues@hadoop.apache.org
Message-ID: <JIRA.12699603.1394282667171.36890.1405359845066@arcas>
In-Reply-To: <JIRA.12699603.1394282667171@arcas>
References: <JIRA.12699603.1394282667171@arcas>
Subject: [jira] [Commented] (MAPREDUCE-5785) Derive task attempt JVM max
 heap size and io.sort.mb automatically from mapreduce.*.memory.mb
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/MAPREDUCE-5785?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D=
14060919#comment-14060919 ]=20

Rohini Palaniswamy commented on MAPREDUCE-5785:
-----------------------------------------------

I was taking a look at https://issues.apache.org/jira/browse/MAPREDUCE-5785=
 and https://issues.apache.org/jira/browse/TEZ-699 .=20
=20
MR:
{code}
public static final float DEFAULT_MEMORY_MB_HEAP_RATIO =3D 1.33f;
float heapRatio =3D conf.getFloat(MRJobConfig.MEMORY_MB_HEAP_RATIO,
          MRJobConfig.DEFAULT_MEMORY_MB_HEAP_RATIO);
int taskHeapSize =3D(int)Math.ceil(taskContainerMb / heapRatio);
public static final float DEFAULT_IO_SORT_MB_HEAP_RATIO =3D 0.5f;
ioSortMbPer =3D JobContext.DEFAULT_IO_SORT_MB_HEAP_RATIO;
+        }
+        sortmb =3D (int)(maxHeapMb * ioSortMbPer);
{code}
Tez:
{code}
public static final String TEZ_CONTAINER_MAX_JAVA_HEAP_FRACTION =3D
+      TEZ_PREFIX + "container.max.java.heap.fraction";
+  public static final double TEZ_CONTAINER_MAX_JAVA_HEAP_FRACTION_DEFAULT =
=3D 0.8;
int maxMemory =3D (int)(resource.getMemory() * maxHeapFactor);
 {code}

Few issues, inconsistencies that I see:
  - The MR one is really confusing. For heap it is divide by and io.sort.mb=
 it is multiplication. I think it would be easier to keep both same to avoi=
d confusion.  I had to apply more of my grey cells to do the division. Woul=
d prefer multiplication to determine the percentage as it is more easy to c=
ompute in mind than division.
   -  io.sort.mb as 50% of heap seems too high for default value. Most of t=
he pig jobs which have huge bags would start failing.
- Another issue is taking the defaults now, for a=20
4G container =E2=80=93 Tez Xmx =3D 3.2G, MR Xmx=3D3.0G
8G container =E2=80=93 Tez Xmx =3D 6.2G, MR xmx =3D 6G.=20
Though the defaults work well for 1 or 2G of memory, for higher memories th=
ey seem to be actually wasting a lot of memory considering not more than 50=
0M is usually required for native memory even if the Xmx keeps increasing. =
We should account that factor into calculation instead of doing Xmx as just=
 a direct percentage of resource.mb.

Tez settings are usually equivalent of MR settings with an internal mapping=
 to the MR setting taking them if they are specified, so that it is easier =
for users to switch between frameworks. This is one thing I am seeing incon=
sistent in terms of how the value is specified and would be good to reconci=
le both to have same behavior.

> Derive task attempt JVM max heap size and io.sort.mb automatically from m=
apreduce.*.memory.mb
> -------------------------------------------------------------------------=
--------------------
>
>                 Key: MAPREDUCE-5785
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-5785
>             Project: Hadoop Map/Reduce
>          Issue Type: New Feature
>          Components: mr-am, task
>            Reporter: Gera Shegalov
>            Assignee: Gera Shegalov
>         Attachments: MAPREDUCE-5785.v01.patch, MAPREDUCE-5785.v02.patch, =
MAPREDUCE-5785.v03.patch
>
>
> Currently users have to set 2 memory-related configs per Job / per task t=
ype.  One first chooses some container size map reduce.\*.memory.mb and the=
n a corresponding maximum Java heap size Xmx < map reduce.\*.memory.mb. Thi=
s makes sure that the JVM's C-heap (native memory + Java heap) does not exc=
eed this mapreduce.*.memory.mb. If one forgets to tune Xmx, MR-AM might be=
=20
> - allocating big containers whereas the JVM will only use the default -Xm=
x200m.
> - allocating small containers that will OOM because Xmx is too high.
> With this JIRA, we propose to set Xmx automatically based on an empirical=
 ratio that can be adjusted. Xmx is not changed automatically if provided b=
y the user.


--
This message was sent by Atlassian JIRA
(v6.2#6252)