[
https://issues.apache.org/jira/browse/MAPREDUCE-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Douglas updated MAPREDUCE-1379:
-------------------------------------
Resolution: Won't Fix
Status: Resolved (was: Patch Available)
Matei is exactly right. As far as I'm aware, no scheduler avoids giving out
reduce work fearing that it could starve itself of map slots. This introduces
corner cases that, without corresponding audit of schedulers, is unlikely to be
handled correctly.
There are many proposals for handling/sharing resources more efficiently, e.g.
MAPREDUCE-297, MAPREDUCE-922, MAPREDUCE-961, MAPREDUCE-279... the current
solution, in contrast, is a violation of the current slot model to get around
the coarse utilization implicit in its design.
Closing as "won't fix"
> Limit both numMapTasks and numReduceTasks
> -----------------------------------------
>
> Key: MAPREDUCE-1379
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-1379
> Project: Hadoop Map/Reduce
> Issue Type: New Feature
> Components: tasktracker
> Affects Versions: 0.22.0
> Reporter: Bochun Bai
> Priority: Trivial
> Attachments: limit-both-numMapTasks-and-numReduceTasks.patch
>
>
> In some environment, the number of concurrent running process is very
> sensitive.
> mapreduce.tasktracker.map.tasks.maximum
> and
> mapreduce.tasktracker.reduce.tasks.maximum
> limit tasks running on each tasktracker separately.
> This patch limits them together, using
> mapreduce.tasktracker.total.tasks.maximum
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
