hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-15950) We are grossly overestimating the memstore size
Date Sat, 04 Jun 2016 01:28:59 GMT

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

Enis Soztutar commented on HBASE-15950:

bq. Nope. JOL is GPL.
Thats a bummer. I was looking under http://hg.openjdk.java.net/code-tools/jol/file/e8e889a8ae3d/src/license,
and saw BSD, but apparently not http://hg.openjdk.java.net/code-tools/jol/file/e8e889a8ae3d/LICENSE.

In any case, we cannot use a JOL or a similar library to estimate byte[] or other non-static
class sizes since the parsing for each instance seems to be pretty costly. I was thinking
of getting the oops size and class size aligning and change our ClassSize to use the dynamic
information. Using Unsafe we can still instantiate KV and other well-known objects and measure
the actual base sizes. 

> We are grossly overestimating the memstore size
> -----------------------------------------------
>                 Key: HBASE-15950
>                 URL: https://issues.apache.org/jira/browse/HBASE-15950
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Enis Soztutar
>            Assignee: Enis Soztutar
>             Fix For: 2.0.0
>         Attachments: Screen Shot 2016-06-02 at 8.48.27 PM.png
> While testing something else, I was loading a region with a lot of data. Writing 30M
cells in 1M rows, with 1 byte values. 
> The memstore size turned out to be estimated as 4.5GB, while with the JFR profiling I
can see that we are using 2.8GB for all the objects in the memstore (KV + KV byte[] + CSLM.Node
+ CSLM.Index). 
> This obviously means that there is room in the write cache that we are not effectively

This message was sent by Atlassian JIRA

View raw message