[
https://issues.apache.org/jira/browse/HBASE-14921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15171434#comment-15171434
]
stack commented on HBASE-14921:
-------------------------------
Really helpful diagram
On #2, you have heard the rumor that MSLAB may not be needed when running on
G1GC (TBD)
Should we move the MSLAB forward so when we pull form the socket on the read of
requests, we read into an MSLAB ([~anoop.hbase]?)
So, when you say the MSLAB can be offheap, its ok to have references only in
CSLM? We do not want to be copying data across the onheap/offheap boundary if
it can be avoided. We can do compare offheap (more a question for our mighty
[~anoop.hbase]).
Just to say that we want this compaction-in-memory feature ON by default. Even
in the case where an in-memory compaction is unable to purge any cells because
all updates are unique, this feature should 'cost' no more than our current
setup. Lets aim for this. We do not want you all doing a bunch of work on
something that folks have to 'enable'. In such a case, only the hbase
cognescenti will get the benefit of your work. So, it looks like you are
talking of doing at least an extra copy from the original MSLAB to a new
Segment MSLAB. Would be cool if a bit of evidence that this extra copy to a
Segment, even in the worst case where no purge was possible, cost less than
trying to continue with a 'fat' CSLM.
"The compaction process can repeat until we must flush to disk. " There will be
guards in place to prevent our compacting in-memory when it not possible that a
compaction can produce a tighter in-memory representation (no purges possible,
etc.)?
First pass. Thanks for the write-up
> Memory optimizations
> --------------------
>
> Key: HBASE-14921
> URL: https://issues.apache.org/jira/browse/HBASE-14921
> Project: HBase
> Issue Type: Sub-task
> Affects Versions: 2.0.0
> Reporter: Eshcar Hillel
> Attachments: CellBlocksSegmentInMemStore.pdf
>
>
> Memory optimizations including compressed format representation and offheap
> allocations
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
