[
https://issues.apache.org/jira/browse/HBASE-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14027397#comment-14027397
]
stack commented on HBASE-11323:
-------------------------------
bq. When I looked last (didn't spend a lot of time, though), it did not look
entirely trivial.
Not sure [~lhofhansl] CombinedBlockCache has special casing currently.
Hopefully can pass a flag from CF down.
bq. Leave the heap for memstore and protobuf garbage; only 512m - 1g for index
blocks in LruBlockCache that only evicts from compactions.
I like your suggestion of simplified LruBlockCache -- no tiers. LruBlockCache
is resizable now because of [~anoop.hbase] ergonomics work. We could have it
so the LruBlockCache starts out big then sizes down to the size of blooms and
indices only.
It is 8G heap w/ 4G to LruBC and then when BucketCache test, it is 8G heap and
4G offheap. I can do another run w/ bigger BC just to see.
bq. One improvement for BucketCache is to have HFileBlock's buf refer directly
to the memory in BucketCache instead of copying it over. Might help, if we can
ensure a block isn't evicted out from under us.
Sounds good to me. Try and get this one in first then we can work on saving
copies.
> BucketCache all the time!
> -------------------------
>
> Key: HBASE-11323
> URL: https://issues.apache.org/jira/browse/HBASE-11323
> Project: HBase
> Issue Type: Sub-task
> Components: io
> Reporter: stack
> Fix For: 0.99.0
>
>
> One way to realize the parent issue is to just enable bucket cache all the
> time; i.e. always have offheap enabled. Would have to do some work to make
> it drop-dead simple on initial setup (I think it doable).
> So, upside would be the offheap upsides (less GC, less likely to go away and
> never come back because of full GC when heap is large, etc.).
> Downside is higher latency. In Nick's BlockCache 101 there is little to no
> difference between onheap and offheap. In a basic compare doing scans and
> gets -- details to follow -- I have BucketCache deploy about 20% less ops
> than LRUBC when all incache and maybe 10% less ops when falling out of cache.
> I can't tell difference in means and 95th and 99th are roughly same (more
> stable with BucketCache). GC profile is much better with BucketCache -- way
> less. BucketCache uses about 7% more user CPU.
> More detail on comparison to follow.
> I think the numbers disagree enough we should probably do the [~lhofhansl]
> suggestion, that we allow you to have a table sit in LRUBC, something the
> current bucket cache layout does not do.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
