hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (MAPREDUCE-3205) MR2 memory limits should be pmem, not vmem
Date Wed, 19 Oct 2011 18:49:12 GMT

     [ https://issues.apache.org/jira/browse/MAPREDUCE-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Todd Lipcon updated MAPREDUCE-3205:
-----------------------------------

    Attachment: mr-3205.txt

Here's a patch implementing the above suggestion:

- {{yarn.nodemanager.resource.memory-gb}} now determines the total physical memory usage for
the NM
- {{yarn.nodemanager.reserved.memory-mb}} no longer exists - it used to be used to determine
the total physical memory for the NM, but now obsoleted by the above.
- {{yarn.nodemanager.vmem.to.pmem.limit.ratio}} sets the overcommit ratio for vmem vs pmem.
This ratio is used both for the total usage across tasks, and for individual tasks.
- resource allocations requested by tasks now allocate physical memory instead of virtual,
with the virtual limit being determined by the above ratio.

I ran a 20 node test last night with the following parameters:
- {{yarn.nodemanager.resource.memory-gb}} = 16
- {{yarn.nodemanager.vmem.to.pmem.limit.ratio}} set to default (2.1)
- {{mapred.child.java.opts}} = -Xmx800m
- {{mapreduce.map.memory.mb}} set to default (1024)

This resulted in a pmem limit of 1024m and vmem limit of 2150m. I ran a terasort and all of
the tasks completed successfully. The VIRTUAL_MEMORY_BYTES counter shows that most of the
tasks were using around 1.2G of vmem. The PHYSICAL_MEMORY_BYTES counter spans from about 500M
to 950M.

Suggestions for how to add an appropriate unit test would be appreciated. Also, if there's
a better way of threading the Configuration object into ContainerImpl, please let me know.

                
> MR2 memory limits should be pmem, not vmem
> ------------------------------------------
>
>                 Key: MAPREDUCE-3205
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-3205
>             Project: Hadoop Map/Reduce
>          Issue Type: Improvement
>          Components: mrv2, nodemanager
>    Affects Versions: 0.23.0
>            Reporter: Todd Lipcon
>         Attachments: mr-3205.txt
>
>
> Currently, the memory resources requested for a container limit the amount of virtual
memory used by the container. On my test clusters, at least, Java processes take up nearly
twice as much vmem as pmem - a Java process running with -Xmx500m uses 935m of vmem and only
about 560m of pmem.
> This will force admins to either under-utilize available physical memory, or oversubscribe
it by configuring the available resources on a TT to be larger than the true amount of physical
RAM.
> Instead, I would propose that the resource limit apply to pmem, and allow the admin to
configure a "vmem overcommit ratio" which sets the vmem limit as a function of pmem limit.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message