[
https://issues.apache.org/jira/browse/HADOOP-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612961#action_12612961
]
Arun C Murthy commented on HADOOP-3136:
---------------------------------------
The problem with today's behaviour is multi-fold:
1. This is a utilization bottleneck, especially when the TaskTracker just
starts up. We should be assigning atleast 50% of it's capacity.
2. If the individual tasks are very short i.e. run for less than the heartbeat
interval the TaskTracker serially runs one task at a time.
3. For jobs with small maps, the TaskTracker never gets a chance to schedule
reduces till all maps are complete. This means shuffle doesn't overlap with
maps at all, another sore-point.
Overall, the right approach is to let the TaskTracker advertise the number of
available map and reduce slots in each heartbeat and the JobTracker (i.e the
Scheduler - HADOOP-3412/HADOOP-3445) should decide how many tasks and which
maps/reduces the TaskTracker should be assigned. Also, we should ensure that
the TaskTracker doesn't run to the JobTracker every-time a task completes -
maybe we should hard-limit to the heartbeat interval or maybe run to the
JobTracker when there are more than one completed tasks in a given heartbeat
interval etc.
> Assign multiple tasks per TaskTracker heartbeat
> -----------------------------------------------
>
> Key: HADOOP-3136
> URL: https://issues.apache.org/jira/browse/HADOOP-3136
> Project: Hadoop Core
> Issue Type: Improvement
> Components: mapred
> Reporter: Devaraj Das
>
> In today's logic of finding a new task, we assign only one task per heartbeat.
> We probably could give the tasktracker multiple tasks subject to the max
> number of free slots it has - for maps we could assign it data local tasks.
> We could probably run some logic to decide what to give it if we run out of
> data local tasks (e.g., tasks from overloaded racks, tasks that have least
> locality, etc.). In addition to maps, if it has reduce slots free, we could
> give it reduce task(s) as well. Again for reduces we could probably run some
> logic to give more tasks to nodes that are closer to nodes running most maps
> (assuming data generated is proportional to the number of maps). For e.g., if
> rack1 has 70% of the input splits, and we know that most maps are data/rack
> local, we try to schedule ~70% of the reducers there.
> Thoughts?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
