You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Enis Soztutar (JIRA)" <ji...@apache.org> on 2016/06/03 03:59:59 UTC

[jira] [Commented] (HBASE-15950) We are grossly overestimating the memstore size

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

Enis Soztutar commented on HBASE-15950:
---------------------------------------

A bit of hacking, here is the breakdown of various sizes: 
{code}
memstore size=4.5 G
memstore KV size=1.8 G               (This is KV objects, excluding the backing array)
memstore KV bytes size=915.5 M (This is underlying byte[] backing KV)
memstore CSLM size=1.8 G          (CSLM internal objects). 
{code}

The real sizes from profiling are (see attached screen shot): 
{code}
memstore size=2.8 G
memstore KV size=915 M               (This is KV objects, excluding the backing array)
memstore KV bytes size=860 M     (This is underlying byte[] backing KV)
memstore CSLM size=686M + 343M          (CSLM internal objects). 
{code}






> 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
>             Fix For: 2.0.0
>
>
> 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 using. 



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