Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Tue, 14 Oct 2014 11:46:35 +0000 (UTC)
From: "Amir Langer (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12748005.1413286212000.262118.1413287195590@Atlassian.JIRA>
In-Reply-To: <JIRA.12748005.1413286212000@Atlassian.JIRA>
References: <JIRA.12748005.1413286212000@Atlassian.JIRA>
 <JIRA.12748005.1413286212112@arcas>
Subject: [jira] [Commented] (HDFS-7244) Reduce Namenode memory using
 Flyweight pattern
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Amir Langer commented on HDFS-7244:
-----------------------------------

Although orthogonal, HDFS-6658 is a first step in this direction, especially the move towards using ids rather object references to define BlockInfo state.


> Reduce Namenode memory using Flyweight pattern
> ----------------------------------------------
>
>                 Key: HDFS-7244
>                 URL: https://issues.apache.org/jira/browse/HDFS-7244
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: namenode
>            Reporter: Amir Langer
>
> Using the flyweight pattern can dramatically reduce memory usage in the Namenode. The pattern also abstracts the actual storage type and allows the decision of whether it is off-heap or not and what is the serialisation mechanism to be configured per deployment. 
> The idea is to move all BlockInfo data (as a first step) to this storage using the Flyweight pattern. The cost to doing it will be in higher latency when accessing/modifying a block. The idea is that this will be offset with a reduction in memory and in the case of off-heap, a dramatic reduction in memory (effectively, memory used for BlockInfo would reduce to a very small constant value).
> This reduction will also have an huge impact on the latency as GC pauses will be reduced considerably and may even end up with better latency results than the original code.
> I wrote a stand-alone project as a proof of concept, to show the pattern, the data structure we can use and what will be the performance costs of this approach.
> see [Slab|https://github.com/langera/slab]
> and [Slab performance results|https://github.com/langera/slab/wiki/Performance-Results].
> Slab abstracts the storage, gives several storage implementations and implements the flyweight pattern for the application (Namenode in our case).
> The stages to incorporate Slab into the Namenode is outlined in the sub-tasks JIRAs.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)