hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Dimiduk (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-11323) BucketCache all the time!
Date Wed, 11 Jun 2014 03:38:02 GMT

    [ https://issues.apache.org/jira/browse/HBASE-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14027372#comment-14027372

Nick Dimiduk commented on HBASE-11323:

+1 for this. I think moving offheap by default is a sound approach, barring any new revelations
re: CMS and/or G1 (cough [~apurtell]). We'll enjoy more stability and have a less complicated
story for folks with gobs of ram.

In this new world, the default RS configuration looks something like 4-6G heap (how many memstores
do you need?) + XXX direct memory. Leave the heap for memstore and protobuf garbage; only
512m - 1g for index blocks in LruBlockCache that only evicts from compactions. It could even
be simplified to remove the 3 different block priorities.

bq. we allow you to have a table sit in LRUBC

I think this becomes pretty easy if we're assuming a CombinedBlockCache is always present.
It's managing the block placement strategy already, so it can check the flag and do the right

bq. I have BucketCache deploy about 20% less ops than LRUBC when all incache and maybe 10%
less ops when falling out of cache.

Must be smallish heap. What are your memory allocations here? Have you tried with 24+G heap?
I think you'll see very different numbers.

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.

> 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

View raw message