[
https://issues.apache.org/jira/browse/HBASE-14921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15207087#comment-15207087
]
stack commented on HBASE-14921:
-------------------------------
bq. The ad hoc memory management is always at least as good as some universal
one. So
Makes sense.
https://issues.apache.org/jira/browse/HBASE-15180?focusedCommentId=15124036&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15124036
is the comment that has G1GC doing better w/ MSLAB off.
bq. So no option, but to copy back from off-heap to on-heap.
We need to fix this... but this is what [~anoop.hbase] and [~ram_krish] are at.
bq. Pay attention that references between off-heap and on-heap are OK (no extra
performance cost), just those accesses are going to be performed differently.
We can measure.
bq. ....we can add such a predictor later, after we have benchmarking for flat
representation and off-heaping..... let us just take the challenges one by one.
Agree
bq.. So assumption is that among big amount of memory you have a higher
probability to find something to compact.
Random thought: There will be metric or TRACE-level logging so can 'see' effect
of in-memory compaction?
bq. ...It cost you CPU cycles only, and if you lower the priority of the
compacting thread even the CPU cycles should not be an issue. So I wouldn’t be
worried so much about the time spent on copy in the compaction time… Am I
missing something?
Just that CPU will be our bottleneck if up on SSD/NVRAM and that you can't set
priority on threads (not in java on linux at least). Minor.
> 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
> Assignee: Anastasia Braginsky
> Attachments: CellBlocksSegmentInMemStore.pdf,
> CellBlocksSegmentinthecontextofMemStore(1).pdf, HBASE-14921-V01.patch,
> HBASE-14921-V02.patch
>
>
> Memory optimizations including compressed format representation and offheap
> allocations
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
