[jira] [Comment Edited] (HBASE-23887) BlockCache performance improve by reduce eviction rate

["Danil Lipovoy (Jira)" <ji...@apache.org>]

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

Danil Lipovoy edited comment on HBASE-23887 at 5/8/20, 6:36 AM:
----------------------------------------------------------------

[~elserj]

>>Can you please update the title/description so your improvement is a little more clear?
Of course, done

>>As I understand it: you choose to not cache a block which we would have
That is correct

>>At least, your solution would have a higher benefit if all data is accessed "equally"
It was before) Now I added 2 parameters which help to control when new logic will be enabled. It means it will work only while heavy reading going on. 
For example, we have not equaly distibution of reading blocks:

1
5
1
1
7 < eviction 5
1
1
7
1
1 < no eviction

In this case eviction will work rarely. And we can use it to control by params:

hbase.lru.cache.heavy.eviction.count.limit - set how many times have to run eviction process that start to avoid of putting data to BlockCache
hbase.lru.cache.heavy.eviction.bytes.size.limit - set how many bytes have to evicted each time that start to avoid of putting data to BlockCache

By default: if 10 times (=100 seconds) evicted more than 10 MB (each time) then we start to skip 50% of data blocks. 

Thats why this feature will work when the data really can't fit into BlockCache -> eviction rate really work hard and it usually means reading blocks evenly distributed.

When heavy evitions process end then new logic off and will put into BlockCache all blocks again.

I am not sure that explain the idea very clean. Please get me know if I need provide more information.

>>What YCSB workload did you run for which these results you've shared
It was Workload C: Read only

>>Also, how much data did you generate and how does that relate to the total blockcache size?
It was 600 Gb in HFiles
Total BlockCache Size 48 Gb



was (Author: pustota):
[~elserj]

>>Can you please update the title/description so your improvement is a little more clear?
Of course, done

>>As I understand it: you choose to not cache a block which we would have
That is correct

>>At least, your solution would have a higher benefit if all data is accessed "equally"
It was before. Now I added 2 parameters which help to control when this logic will be enabled. It means it will work only while heavy reading going on. 
For example, we have not equaly distibution of reading blocks:

1
5
1
1
7 < eviction 5
1
1
7
1
1 < no eviction

In this case eviction will work rarely. And we can use it to control by params:

hbase.lru.cache.heavy.eviction.count.limit - set how many times have to run eviction process that start to avoid of putting data to BlockCache
hbase.lru.cache.heavy.eviction.bytes.size.limit - set how many bytes have to evicted each time that start to avoid of putting data to BlockCache

By default: if 10 times (=100 seconds) evicted more than 10 MB (each time) then we start to skip 50% of data blocks. 

Thats why this feature will work when the data really can't fit into BlockCache -> eviction rate really work hard and it usually means reading blocks evenly distributed.

When heavy evitions process end then new logic off and will put into BlockCache all blocks again.

I am not sure that explain the idea very clean. Please get me know if I need provide more information.

>>What YCSB workload did you run for which these results you've shared
It was Workload C: Read only

>>Also, how much data did you generate and how does that relate to the total blockcache size?
It was 600 Gb in HFiles
Total BlockCache Size 48 Gb


> BlockCache performance improve by reduce eviction rate
> ------------------------------------------------------
>
>                 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: 1582787018434_rs_metrics.jpg, 1582801838065_rs_metrics_new.png, BC_LongRun.png, cmp.png, evict_BC100_vs_BC23.png, read_requests_100pBC_vs_23pBC.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. 
> Sometimes we have more data than can fit into BlockCache and it is cause a high rate of evictions. In this case we can skip cache a block N and insted cache the N+1th block. Anyway we would evict N block quite soon and that why that skipping good for performance.
> Example:
> Imagine we have little cache, just can fit only 1 block and we are trying to read 3 blocks with offsets:
> 124
> 198
> 223
> Current way - we put the block 124, then put 198, evict 124, put 223, evict 198. A lot of work (5 actions).
> With the feature - 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 *hbase.lru.cache.data.block.percent* = 50) go into the cache. And skip others. It means we will not try to handle the block 198 and save CPU for other job. In the result - we put block 124, then put 223, evict 124 (3 actions). 
> 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 1-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}
>  
> Other parameters help to control when this logic will be enabled. It means it will work only while heavy reading going on.
> hbase.lru.cache.heavy.eviction.count.limit - set how many times have to run eviction process that start to avoid of putting data to BlockCache
> hbase.lru.cache.heavy.eviction.bytes.size.limit - set how many bytes have to evicted each time that start to avoid of putting data to BlockCache
> By default: if 10 times (100 secunds) evicted more than 10 MB (each time) then we start to skip 50% of data blocks.
> When heavy evitions process end then new logic off and will put into BlockCache all blocks again.
>  
> 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)