[
https://issues.apache.org/jira/browse/HADOOP-4766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653432#action_12653432
]
Runping Qi commented on HADOOP-4766:
------------------------------------
Did one more test with JT heapsize set to 3GB (Hadoop trunk).
Looks like the previously reported weird behavior is not reproducible, --- that
is the good news:)
The results of this test are better than those gotten with JT heapsize set to
2GB.
Here are the details:
First run of gridmix2: 32 minutes
Second run of gridmix2: 35 minutes
Third run: 44 minutes
Fourth run: JT non responsive after the 650th job was submitted, maxing one cpu.
Even though I set maximim jobs kept in memory to 500, I actually saw 590 jobs
through the web UI.
> 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
> Priority: Blocker
> Fix For: 0.18.3, 0.19.1, 0.20.0
>
>
> 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 minutes.
> 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 non-responsive.
> 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.
