hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joydeep Sen Sarma (JIRA)" <j...@apache.org>
Subject [jira] Updated: (MAPREDUCE-2116) optimize getTasksToKill to reduce JobTracker contention
Date Thu, 07 Oct 2010 08:09:32 GMT

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

Joydeep Sen Sarma updated MAPREDUCE-2116:
-----------------------------------------

    Description: 
getTasksToKill shows up as one of the top routines holding the JT lock. Specifically, the
translation from attemptid to tip is very expensive:

        at java.util.TreeMap.getEntry(TreeMap.java:328)
        at java.util.TreeMap.get(TreeMap.java:255)
        at org.apache.hadoop.mapred.TaskInProgress.shouldClose(TaskInProgress.java:500)
        at org.apache.hadoop.mapred.JobTracker.getTasksToKill(JobTracker.java:3464)
          locked <0x00002aab6ebb6640> (a org.apache.hadoop.mapred.JobTracker)
        at org.apache.hadoop.mapred.JobTracker.heartbeat(JobTracker.java:3181)


this seems like an avoidable expense since the tip for a given attempt is fixed (and one should
not need a map lookup to find the association). on a different note - not clear to me why
TreeMaps are in use here (i didn't find any iteration over these maps). any background info
on why things are arranged the way they are would be useful.

  was:
getTasksToKill shows up as one of the top routines holding the JT lock. Specifically, the
translation from attemptid to tip is very expensive:

        at java.util.TreeMap.getEntry(TreeMap.java:328)
        at java.util.TreeMap.get(TreeMap.java:255)
        at org.apache.hadoop.mapred.TaskInProgress.shouldClose(TaskInProgress.java:500)
        at org.apache.hadoop.mapred.JobTracker.getTasksToKill(JobTracker.java:3464)
        - locked <0x00002aab6ebb6640> (a org.apache.hadoop.mapred.JobTracker)
        at org.apache.hadoop.mapred.JobTracker.heartbeat(JobTracker.java:3181)


this seems like an avoidable expense since the tip for a given attempt is fixed (and one should
not need a map lookup to find the association). on a different note - not clear to me why
TreeMaps are in use here (i didn't find any iteration over these maps). any background info
on why things are arranged the way they are would be useful.


> optimize getTasksToKill to reduce JobTracker contention
> -------------------------------------------------------
>
>                 Key: MAPREDUCE-2116
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-2116
>             Project: Hadoop Map/Reduce
>          Issue Type: Improvement
>          Components: jobtracker
>            Reporter: Joydeep Sen Sarma
>
> getTasksToKill shows up as one of the top routines holding the JT lock. Specifically,
the translation from attemptid to tip is very expensive:
>         at java.util.TreeMap.getEntry(TreeMap.java:328)
>         at java.util.TreeMap.get(TreeMap.java:255)
>         at org.apache.hadoop.mapred.TaskInProgress.shouldClose(TaskInProgress.java:500)
>         at org.apache.hadoop.mapred.JobTracker.getTasksToKill(JobTracker.java:3464)
>           locked <0x00002aab6ebb6640> (a org.apache.hadoop.mapred.JobTracker)
>         at org.apache.hadoop.mapred.JobTracker.heartbeat(JobTracker.java:3181)
> this seems like an avoidable expense since the tip for a given attempt is fixed (and
one should not need a map lookup to find the association). on a different note - not clear
to me why TreeMaps are in use here (i didn't find any iteration over these maps). any background
info on why things are arranged the way they are would be useful.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message