hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anoop Sam John (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17739) BucketCache is inefficient/wasteful/dumb in its bucket allocations
Date Wed, 22 Mar 2017 18:03:41 GMT

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

Anoop Sam John commented on HBASE-17739:

Thanks.  Ya I missed some parts like Object size as such and CSLM entry size.  My math comes
this way
String hfileName  -  Ref  - 4
long offset  - 8
BlockType blockType  - Ref  - 4
boolean isPrimaryReplicaBlock  - 1
Total  =  12 (Object) + 17 = 29

int offsetBase  -  4
int length  - 4
byte offset1  -  1
byte deserialiserIndex  -  1
long accessCounter  -  8
BlockPriority priority  - Ref  - 4
volatile boolean markedForEvict  -  1
AtomicInteger refCount  -  16 + 4
long cachedTime  -  8
Total = 12 (Object) + 51 = 63

ConcurrentHashMap Map.Entry  -  40
blocksByHFile ConcurrentSkipListSet Entry  -  40

Total = 29 + 63 + 80 = 172

May be u considering 8 as the Reference size.  I am following what ClassSize returns.  Pls
refer UnsafeLayout

Ya it is big only I agree.   For 10 million entries we will end up having 1.6 GB heap size.
 (Say considering 64 KB block size, 10 million means 600 GB cache size).

I went through this some time back also.  Seeing how far we grow in heap size when growing
really big with BC.  But some calc did not get correctly and it was not coming this big.
Let me raise an issue. I can see some possibility to reduce this. Any reduction here will
help us for sure.

Thanks Vladimir for raising the concern.

> BucketCache is inefficient/wasteful/dumb in its bucket allocations
> ------------------------------------------------------------------
>                 Key: HBASE-17739
>                 URL: https://issues.apache.org/jira/browse/HBASE-17739
>             Project: HBase
>          Issue Type: Sub-task
>          Components: BucketCache
>            Reporter: stack
> By default we allocate 14 buckets with sizes from 5K to 513K. If lots of heap given over
to bucketcache and say no allocattions made for a particular bucket size, this means we have
a bunch of the bucketcache that just goes idle/unused.
> For example, say heap is 100G. We'll divide it up among the sizes. If say we only ever
do 5k records, then most of the cache will go unused while the allocation for 5k objects will
see churn.
> Here is an old note of [~anoop.hbase]'s' from a conversation on bucket cache we had offlist
that describes the issue:
> "By default we have those 14 buckets with size range of 5K to 513K.
>   All sizes will have one bucket (with size 513*4) each except the
> last size.. ie. 513K sized many buckets will be there.  If we keep on
> writing only same sized blocks, we may loose all in btw sized buckets.
> Say we write only 4K sized blocks. We will 1st fill the bucket in 5K
> size. There is only one such bucket. Once this is filled, we will try
> to grab a complete free bucket from other sizes..  But we can not take
> it from 9K... 385K sized ones as there is only ONE bucket for these
> sizes.  We will take only from 513 size.. There are many in that...
> So we will eventually take all the buckets from 513 except the last
> one.. Ya it has to keep at least one in evey size..     So we will
> loose these much size.. They are of no use."
> We should set the size type on the fly as the records come in.
> Or better, we should choose record size on the fly. Here is another comment from [~anoop.hbase]:
> "The second is the biggest contributor.  Suppose instead of 4K
> sized blocks, the user has 2 K sized blocks..  When we write a block to bucket slot,
we will reserve size equal to the allocated size for that block.
> So when we write 2K sized blocks (may be actual size a bit more than
> 2K ) we will take 5K with each of the block.  So u can see that we are
> loosing ~3K with every block. Means we are loosing more than half."
> He goes on: "If am 100% sure that all my table having 2K HFile block size, I need to
give this config a value 3 * 1024 (Exact 2 K if I give there may be
> again problem! That is another story we need to see how we can give
> more guarantee for the block size restriction HBASE-15248)..  So here also ~1K loose
for every 2K.. So some thing like a 30% loose !!! :-(“"
> So, we should figure the record sizes ourselves on the fly.
> Anything less has us wasting loads of cache space, nvm inefficiences lost because of
how we serialize base types to cache.

This message was sent by Atlassian JIRA

View raw message