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

Danil Lipovoy edited comment on HBASE-23887 at 2/26/20 6:04 PM:
----------------------------------------------------------------

[~reidchan] 

 

Made more tests with YCSB.
 In the background run 20 threads witch emulate random access other users and 
run YSCB with 100 threads where _requestdistribution_ = zipfian/latest and 
uniform.
 Other changes is tuning _hbase.lru.cache.data.block.percent_ to 8, it is value 
when data blocks exactly fit to BlockCache (see the picture in attachment).

Below comparing the results:

*UNIFORM, hbase.lru.cache.data.block.percent=100*
 [OVERALL], RunTime(ms), 36278
 [OVERALL], Throughput(ops/sec), *27564*.915375709796

*UNIFORM, hbase.lru.cache.data.block.percent=8*
 [OVERALL], RunTime(ms), 18752
 [OVERALL], Throughput(ops/sec), *53327*.64505119454

*LATEST, hbase.lru.cache.data.block.percent=100*
 [OVERALL], RunTime(ms), 36015
 [OVERALL], Throughput(ops/sec), *27766*.20852422602

*LATEST, hbase.lru.cache.data.block.percent=8*
 [OVERALL], RunTime(ms), 21773
 [OVERALL], Throughput(ops/sec), *45928*.443485050295

*ZIPFIAN, hbase.lru.cache.data.block.percent=100*
 [OVERALL], RunTime(ms), 36480
 [OVERALL], Throughput(ops/sec), *27412*.280701754386

*ZIPFIAN, hbase.lru.cache.data.block.percent=8*
 [OVERALL], RunTime(ms), 24828
 [OVERALL], Throughput(ops/sec), *40277*.10649266957

 

But I noticed a problem with metrics. "Block Cache Blocks Cached" grows undless 
(see the attach).

The problem in HFileReaderImpl:
{code:java}
if (updateCacheMetrics && hfileBlock.getBlockType().isData()) {
 HFile.DATABLOCK_READ_COUNT.increment();
}{code}
This counter doesn't know that blocks wasn't cached. 
 Not sure, how to better fix it, any ideas?


was (Author: pustota):
[~reidchan] 

 

Made more tests with YCSB.
 In the background run 20 threads witch emulate random access other users and 
run YSCB with 100 threads where requestdistribution = zipfian/latest and 
uniform.
 Other changes is tuning _hbase.lru.cache.data.block.percent_ to 8, it is value 
when data blocks exactly fit to BlockCache (see the picture in attachment).


 Below comparing the results:

*UNIFORM, hbase.lru.cache.data.block.percent=100*
 [OVERALL], RunTime(ms), 36278
 [OVERALL], Throughput(ops/sec), *27564*.915375709796

*UNIFORM, hbase.lru.cache.data.block.percent=8*
 [OVERALL], RunTime(ms), 18752
 [OVERALL], Throughput(ops/sec), *53327*.64505119454

*LATEST, hbase.lru.cache.data.block.percent=100*
 [OVERALL], RunTime(ms), 36015
 [OVERALL], Throughput(ops/sec), *27766*.20852422602

*LATEST, hbase.lru.cache.data.block.percent=8*
 [OVERALL], RunTime(ms), 21773
 [OVERALL], Throughput(ops/sec), *45928*.443485050295

*ZIPFIAN, hbase.lru.cache.data.block.percent=100*
 [OVERALL], RunTime(ms), 36480
 [OVERALL], Throughput(ops/sec), *27412*.280701754386

*ZIPFIAN, hbase.lru.cache.data.block.percent=8*
 [OVERALL], RunTime(ms), 24828
 [OVERALL], Throughput(ops/sec), *40277*.10649266957

 

But I noticed a problem with metrics. "Block Cache Blocks Cached" grows undless 
(see the attach).

The problem in HFileReaderImpl:
{code:java}
if (updateCacheMetrics && hfileBlock.getBlockType().isData()) {
 HFile.DATABLOCK_READ_COUNT.increment();
}{code}
This counter doesn't know that blocks wasn't cached. 
 Not sure, how to better fix it, any ideas?

> 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)

Reply via email to