[
https://issues.apache.org/jira/browse/HBASE-16417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15725961#comment-15725961
]
Anoop Sam John commented on HBASE-16417:
----------------------------------------
Why I mentioned abt correcting the GC config and HBase config is that ur tests
on data compaction was not using MSLAB where as others. (The initial
compares).. So the GC is paying the cost and it might be giving a false
indication that data compaction is better. Ya data compaction might be better
depending on the key generation. More and more duplicated keys
(rk+cf+q+ts+type) means in memory compaction can get rid of many (def table
versions = 1).. But I dont think by def we should enable this.
Yes we need to consider that more users will go to G1GC. So as per ur tests u
say disable memstore chunk pool by default but enable MSLAB is ok? This was/is
on by def from long time.
I strongly feel we should revisit our BC and memstore % def values. Specially
to conisder that we will ON L2 off heap now. The data blocks will go to L2. L1
might have only index blocks.. So we dont need much size there. Even pls note
that off heap backed MSLAB pool is all ready in trunk.. We will do tests
similar to urs by working with off heap.
> In-Memory MemStore Policy for Flattening and Compactions
> --------------------------------------------------------
>
> Key: HBASE-16417
> URL: https://issues.apache.org/jira/browse/HBASE-16417
> Project: HBase
> Issue Type: Sub-task
> Reporter: Anastasia Braginsky
> Assignee: Eshcar Hillel
> Fix For: 2.0.0
>
> Attachments: HBASE-16417-benchmarkresults-20161101.pdf,
> HBASE-16417-benchmarkresults-20161110.pdf,
> HBASE-16417-benchmarkresults-20161123.pdf,
> HBASE-16417-benchmarkresults-20161205.pdf
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
