[
https://issues.apache.org/jira/browse/HBASE-17765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15904620#comment-15904620
]
Anoop Sam John commented on HBASE-17765:
----------------------------------------
So here the merge means the cell data also will get copied to new MSLAB right?
Or it is just merge of the index data?
Ya make that 30 to be configurable is fine IMO.
In ur tests how much this #segments in pipeline gets to? As per the math it
can not be more than 16 no?
Default 128 MB flush size and 4x as blocking factor. And 25% of flush size is
what the in memory flush cap. So we can have 4 * 4 segments at max in
pipeline? Or my math is somewhere wrong? Accordingly the default of this
config we need to adjust. IMO than a 30 value, we should do this way.. When
the config values of this in memory flush factor and/or blocking factor
changes, we need to adjust this new config so as to make the default way of no
merge. Ya one can always change it then.
> Reviving the merge possibility in the CompactingMemStore
> --------------------------------------------------------
>
> Key: HBASE-17765
> URL: https://issues.apache.org/jira/browse/HBASE-17765
> Project: HBase
> Issue Type: Sub-task
> Reporter: Anastasia Braginsky
> Assignee: Anastasia Braginsky
> Fix For: 2.0.0
>
> Attachments: HBASE-17765-V01.patch
>
>
> According to the new performance results presented in the HBASE-16417 we see
> that the read latency of the 90th percentile of the BASIC policy is too big
> due to the need to traverse through too many segments in the pipeline. In
> this JIRA we correct the bug in the merge sizing calculations and allow
> pipeline size threshold to be a configurable parameter.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
