[
https://issues.apache.org/jira/browse/HBASE-23887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044194#comment-17044194
]
Danil Lipovoy edited comment on HBASE-23887 at 2/25/20 8:59 AM:
----------------------------------------------------------------
[~reidchan]
Yes, of course, you do great job as maintainers and you have to khow all
details about it.
I just now provided some details into comments PR, let copy part of it here and
answer for your questions with that example.
Imagine we have little cache. Just for 1 block and trying to read 3 blocks with
offsets:
124
198
223
Original old way - we put the block 124, then put 198, evict 124, put 223,
evict 198. A lot of work (5 actions).
With the patch - last few digits evenly distributed from 0 to 99. When we
divide by modulus we got:
124 -> 24
198 -> 98
223 -> 23
It helps to sort them. Some part, for example below 50 (if we set
cacheDataBlockPercent = 50) go into the cache. And skip others. It means we
will not try work with the block 198 and save CPU for other job. In the result
- we put block 124, then put 223, evict 124 (3 actions).
About the random point. You are absolutely right, it is not trully random and
this is good, because open the door for next improovments. We could don't even
try to get data blocks witch can't be in the cache. It is 119 in our case
above. If we use something like Random functions and skip really random blocks
we close this opportunity (because can't know is it in the cache or not).
I collect few first 10 offset from real requests:
1028307681
52897173
52615009
52988632
53586349
1534493828
651126
1595437225
457603970
1018982096
We can see that last 2 digits evenly distributed and not concentrate around 00
or somewhere else. Thats why we don't face the problems where some hot area
will missed, because they are all different.
About documentation - I would popose give some explanation like: use that
parameter if you read much more then could fit into the cache and can't use L2.
Let me know please, what points not enough explained, I will try to provide
more details.
was (Author: pustota):
[~reidchan]
Yes, of course, you do great job as maintainers and you have to khow all
details about it.
I just now provided some details into comments PR, let copy part of it here and
answer for your questions with that example.
Imagine we have little cache. Just for 1 block and trying to read 3 blocks with
offsets:
124
198
223
Original old way - we put the block 124, then put 198, evict 124, put 223,
evict 198. A lot of work (5 actions).
With the patch - last few digits evenly distributed from 0 to 99. When we
divide by modulus we got:
124 -> 24
198 -> 98
223 -> 23
It helps to sort them. Some part, for example below 50 (if we set
cacheDataBlockPercent = 50) go into the cache. And skip others. It means we
will not try work with the block 198 and save CPU for other job. In the result
- we put block 124, then put 223, evict 124 (3 actions).
About the random point. You are absolutely right, it is not trully random and
this is good, because open the door for next improovments. We could don't even
try to get data blocks with can't be in the cache. 119 in our case above. If we
use something like Random functions and skip really random blocks we close this
opportunity.
I collect few first 10 offset from real requests:
1028307681
52897173
52615009
52988632
53586349
1534493828
651126
1595437225
457603970
1018982096
We can see that last 2 digits evenly distributed and not concentrate around 00
or somewhere else. Thats why we don't face the problems where some hot area
will missed, because they are all different.
About documentation - I would popose give some explanation like: use that
parameter if you read much more then could fit into the cache and can't use L2.
Let me know please, what points not enough explained, I will try to provide
more details.
> BlockCache performance improve
> ------------------------------
>
> Key: HBASE-23887
> URL: https://issues.apache.org/jira/browse/HBASE-23887
> Project: HBase
> Issue Type: Improvement
> Components: BlockCache, Performance
> Reporter: Danil Lipovoy
> Priority: Minor
> Attachments: cmp.png
>
>
> Hi!
> I first time here, correct me please if something wrong.
> I want propose how to improve performance when data in HFiles much more than
> BlockChache (usual story in BigData). The idea - caching only part of DATA
> blocks. It is good becouse LruBlockCache starts to work and save huge amount
> of GC. See the picture in attachment with test below. Requests per second is
> higher, GC is lower.
>
> The key point of the code:
> Added the parameter: *hbase.lru.cache.data.block.percent* which by default =
> 100
>
> But if we set it 0-99, then will work the next logic:
>
>
> {code:java}
> public void cacheBlock(BlockCacheKey cacheKey, Cacheable buf, boolean
> inMemory) {
> if (cacheDataBlockPercent != 100 && buf.getBlockType().isData())
> if (cacheKey.getOffset() % 100 >= cacheDataBlockPercent)
> return;
> ...
> // the same code as usual
> }
> {code}
>
>
> Descriptions of the test:
> 4 nodes E5-2698 v4 @ 2.20GHz, 700 Gb Mem.
> 4 RegionServers
> 4 tables by 64 regions by 1.88 Gb data in each = 600 Gb total (only FAST_DIFF)
> Total BlockCache Size = 48 Gb (8 % of data in HFiles)
> Random read in 20 threads
>
> I am going to make Pull Request, hope it is right way to make some
> contribution in this cool product.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
