hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-11323) BucketCache all the time!
Date Thu, 19 Jun 2014 19:44:25 GMT

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

stack commented on HBASE-11323:

Options are shaping up as follows (copied from HBASE-11364):

1. Do NOT enable offheap by default. Just talk it up as the way to go underlining it will
make pure in-memory access slower (but you can make it so some of your tables are pegged in
memory if you want because of the flag here). Upside: No surprise. Downside: Folks don't read
manuals nor change defaults.
2. Enable offheap BucketCache using CombinedBucketCache. When folks upgrade, latency to user-level
DATA blocks will go up. Upsides: less GC, more cached. Downside: those who notice added latency
might get upset. Changing schema will require alter table.
3. Enable offheap BucketCache but in additive mode where we just add in an L2 under the L1
LruBlockCache. Upside: Additive. Downside: Could make for more GC.
Of the above, maybe 1. is the way to go? 2. may surprise in that perf and GC gets better of
a sudden (this would be ok) but others may be surprised that their latencies have gone up
for some key tables. 3. may actually make GC worse (at least that is case in the SlabCache
case which is similar and the L1/L2 layout doesn't get good review to date going by HBASE-8894).
Will test 3.

> 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
>         Attachments: ReportBlockCache.pdf
> 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