Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sun, 24 Jul 2016 11:31:20 +0000 (UTC)
From: "Anastasia Braginsky (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12989374.1468481917000.117688.1469359880543@Atlassian.JIRA>
In-Reply-To: <JIRA.12989374.1468481917000@Atlassian.JIRA>
References: <JIRA.12989374.1468481917000@Atlassian.JIRA> <JIRA.12989374.1468481917459@arcas>
Subject: [jira] [Commented] (HBASE-16229) Cleaning up size and heapSize
 calculation
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Sun, 24 Jul 2016 11:31:22 -0000


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

Anastasia Braginsky commented on HBASE-16229:
---------------------------------------------

I found this JIRA due to Code Review of HBASE-14921 comment. 

Pay attention that some cases here are sensitive and where done on purpose. At least in 14921 the heap size can be known only by Segment as only Segment knows what type it is.
Going to review this patch...

> Cleaning up size and heapSize calculation
> -----------------------------------------
>
>                 Key: HBASE-16229
>                 URL: https://issues.apache.org/jira/browse/HBASE-16229
>             Project: HBase
>          Issue Type: Sub-task
>    Affects Versions: 2.0.0
>            Reporter: Anoop Sam John
>            Assignee: Anoop Sam John
>             Fix For: 2.0.0
>
>         Attachments: HBASE-16229.patch, HBASE-16229_V2.patch, HBASE-16229_V3.patch
>
>
> It is bit ugly now. For eg:
> AbstractMemStore
> {code}
> public final static long FIXED_OVERHEAD = ClassSize.align(
>       ClassSize.OBJECT +
>           (4 * ClassSize.REFERENCE) +
>           (2 * Bytes.SIZEOF_LONG));
>   public final static long DEEP_OVERHEAD = ClassSize.align(FIXED_OVERHEAD +
>       (ClassSize.ATOMIC_LONG + ClassSize.TIMERANGE_TRACKER +
>       ClassSize.CELL_SKIPLIST_SET + ClassSize.CONCURRENT_SKIPLISTMAP));
> {code}
> We include the heap overhead of Segment also here. It will be better the Segment contains its overhead part and the Memstore impl uses the heap size of all of its segments to calculate its size.
> Also this
> {code}
> public long heapSize() {
>     return getActive().getSize();
>   }
> {code}
> HeapSize to consider all segment's size not just active's. I am not able to see an override method in CompactingMemstore.
> This jira tries to solve some of these.
> When we create a Segment, we seems pass some initial heap size value to it. Why?  The segment object internally has to know what is its heap size not like some one else dictate it.
> More to add when doing this cleanup


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