[
https://issues.apache.org/jira/browse/HBASE-14613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14970461#comment-14970461
]
stack commented on HBASE-14613:
-------------------------------
Yeah, I think we should keep memstorechunkpool -- not reallocating is always
good... (let me check synchronize) -- but make it work in new context: use
chore and make it resizeable. Can do the [~enis] suggestion of Allocator
Interface NP. Let me also try offheaping the slabs (presuming that it access of
offheap is same as onheap, its just the offheap allocation that is slow).
Tell me more about your equation [~enis]? Ideally, the pool is the size that
the memstore will grow too in the next N seconds -- we want to minimize
allocations -- but then what to do in case where pool == memstore size, we
flush, and then we don't get any more writes? When do we let the pool go?
Thanks.
> Remove MemStoreChunkPool?
> -------------------------
>
> Key: HBASE-14613
> URL: https://issues.apache.org/jira/browse/HBASE-14613
> Project: HBase
> Issue Type: Brainstorming
> Reporter: Lars Hofhansl
> Priority: Minor
> Attachments: 14613-0.98.txt, gc.png, writes.png
>
>
> I just stumbled across MemStoreChunkPool. The idea behind is to reuse chunks
> of allocations rather than letting the GC handle this.
> Now, it's off by default, and it seems to me to be of dubious value. I'd
> recommend just removing it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
