hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amar Kamat (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-4766) Hadoop performance degrades significantly as more and more jobs complete
Date Tue, 13 Jan 2009 05:59:00 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-4766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12663238#action_12663238

Amar Kamat commented on HADOOP-4766:

bq. should we set the default value of mapred.jobtracker.maximum.usable.memory.percent to
0.75 or some such, rather than 1.0?
Earlier versions of the patch had the default set to 0.75. But then I realized that by default
we should turn off this feature/code and let the admins decide what the right percentage should
be. For example for a heap size of 1 GB, 750MB makes sense but for a heap size of 8GB, 6GB
is too less and maybe 7.5GB i.e ~0.9 makes more sense. 

bq. Also, we should call it mapred.jobtracker.jobhistory.heap.limit, the current one might
confuse users?
Actually the memory is the overall usage i.e JT + all-jobs and hence I named it as usable
memory. Let me know it needs to be renamed.

> Hadoop performance degrades significantly as more and more jobs complete
> ------------------------------------------------------------------------
>                 Key: HADOOP-4766
>                 URL: https://issues.apache.org/jira/browse/HADOOP-4766
>             Project: Hadoop Core
>          Issue Type: Bug
>          Components: mapred
>    Affects Versions: 0.18.2, 0.19.0
>            Reporter: Runping Qi
>            Assignee: Amar Kamat
>            Priority: Blocker
>         Attachments: HADOOP-4766-v1.patch, HADOOP-4766-v2.10.patch, HADOOP-4766-v2.4.patch,
HADOOP-4766-v2.6.patch, HADOOP-4766-v2.7-0.18.patch, HADOOP-4766-v2.7-0.19.patch, HADOOP-4766-v2.7.patch,
HADOOP-4766-v2.8-0.18.patch, HADOOP-4766-v2.8-0.19.patch, HADOOP-4766-v2.8.patch, map_scheduling_rate.txt
> When I ran the gridmix 2 benchmark load on a fresh cluster of 500 nodes with hadoop trunk,

> the gridmix load, consisting of 202 map/reduce jobs of various sizes, completed in 32
> Then I ran the same set of the jobs on the same cluster, yhey completed in 43 minutes.
> When I ran them the third times, it took (almost) forever --- the job tracker became
> The job  tracker's heap size was set to 2GB. 
> The cluster is configured to keep up to 500 jobs in memory.
> The job tracker kept one cpu busy all the time. Look like it was due to GC.
> I believe the release 0.18/0.19 have the similar behavior.
> I believe 0.18 and 0.18 also have the similar behavior.

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

View raw message