hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-2555) Improve CheckPoint node GC performance
Date Wed, 16 Nov 2011 18:56:51 GMT

    [ https://issues.apache.org/jira/browse/HDFS-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13151421#comment-13151421
] 

Todd Lipcon commented on HDFS-2555:
-----------------------------------

What if we just called System.gc a few times after reassigning rootDir? Wouldn't that end
up cleaning up all the memory?

(Also, what's the end goal of this? The heap size increasing isn't really a problem in itself,
so long as it eventually  cleans itself up before it OOMEs)
                
> Improve CheckPoint node GC performance
> --------------------------------------
>
>                 Key: HDFS-2555
>                 URL: https://issues.apache.org/jira/browse/HDFS-2555
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: name-node
>            Reporter: Bochun Bai
>         Attachments: HDFS-2555-for-0.21.0.patch
>
>
> CheckPoint NameNode uses a lot of memory to merge the edits to the fsimage.
> And the previous checkpoint data cannot easily be GCed.
> It is running with jdk-sun-1.6 with different GC parameters, JProfiler calculated heap
size shown below:
>   For 1MB sized fsimage, -XX:-UseConcMarkSweepGC, heap size increases 10MB every checking
period.
>   For 1MB sized fsimage, -XX:-UseParallelGC, heap size increases and back to 10M every
checking period.
>   For 1.2GB sized fsimage, both GC mode, heap size increases 2.5GB every checking period.
> I have two workaround, both of them are tested work fine. But I want discuss more about
the CheckPoint design.
>   Workaround 1: set the check period to a very long time, and restart the java process
every hour. 
>     Pro: solves full GC problem immediately.
>     Con: Cannot merge edits when it increased suddenly.
>   Workaround 2: also reset the INode tree structure when reset the root node.
>     Pro: both CMS and Parallel mode works
>     Con: This may be a JDK-specific problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message