[ https://issues.apache.org/jira/browse/MAPREDUCE-5785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215319#comment-14215319 ]
Allen Wittenauer edited comment on MAPREDUCE-5785 at 11/17/14 10:35 PM: ------------------------------------------------------------------------ bq. Technically this may need to be marked as an incompatible change I agree: this will likely break all kinds of user jobs. I don't even want to consider what happens in the streaming and pipes use cases.... was (Author: aw): bq. Technically this may need to be marked as an incompatible change +1 This will likely break all kinds of user jobs. I don't even want to consider what happens in the streaming and pipes use cases.... > Derive task attempt JVM max heap size and io.sort.mb automatically from > mapreduce.*.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 type. > One first chooses some container size map reduce.\*.memory.mb and then a > corresponding maximum Java heap size Xmx < map reduce.\*.memory.mb. This > makes sure that the JVM's C-heap (native memory + Java heap) does not exceed > this mapreduce.*.memory.mb. If one forgets to tune Xmx, MR-AM might be > - allocating big containers whereas the JVM will only use the default > -Xmx200m. > - 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 by > the user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)