[
https://issues.apache.org/jira/browse/HBASE-19506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16310857#comment-16310857
]
Anoop Sam John commented on HBASE-19506:
----------------------------------------
Very happy to see u coming up with real math.. The under utilization was my
concern from day 1.. I like the way u reasoning out things.
bq.Where does the number 52800 come from ?
A math issue? 12800 * 5 is what she was saying.
So the idea is to have a smaller sized chunk's pool and use that for the index
meta data. When we use CCM this pool will be ON and will be used.
bq.Let's say chunks of 256KB size
So when one in memory flush or compaction require more size than this (for the
index meta data), we will use more than one chunk. Correct? Only thing is how
we decide the #BBs in this new pool. On what basis. Ya the idea seems
interesting. Hope u will come out with a more detailed plan. Good one...
> Support variable sized chunks from ChunkCreator
> -----------------------------------------------
>
> Key: HBASE-19506
> URL: https://issues.apache.org/jira/browse/HBASE-19506
> Project: HBase
> Issue Type: Sub-task
> Reporter: Anastasia Braginsky
>
> When CellChunkMap is created it allocates a special index chunk (or chunks)
> where array of cell-representations is stored. When the number of
> cell-representations is small, it is preferable to allocate a chunk smaller
> than a default value which is 2MB.
> On the other hand, those "non-standard size" chunks can not be used in pool.
> On-demand allocations in off-heap are costly. So this JIRA is about to
> investigate the trade of between memory usage and the final performance.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)