[
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 7:03 PM:
----------------------------------------------------------------
Did 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). First run is current version, the second with the feature.
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?
PS The attachment has lost, will add it tomorrow.
was (Author: pustota):
Did 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). First run is current version, the second with the feature.
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?
PS The attachment is lost, will add it tomorrow.
> 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)
