virajjasani commented on a change in pull request #3215:
URL: https://github.com/apache/hbase/pull/3215#discussion_r638493210
##########
File path:
hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/TinyLfuBlockCache.java
##########
@@ -158,7 +158,13 @@ public boolean containsBlock(BlockCacheKey cacheKey) {
@Override
public Cacheable getBlock(BlockCacheKey cacheKey,
boolean caching, boolean repeat, boolean updateCacheMetrics) {
- Cacheable value = cache.getIfPresent(cacheKey);
+ Cacheable value = cache.asMap().computeIfPresent(cacheKey, (blockCacheKey,
cacheable) -> {
+ // It will be referenced by RPC path, so increase here. NOTICE: Must do
the retain inside
+ // this block. because if retain outside the map#computeIfPresent, the
evictBlock may remove
+ // the block and release, then we're retaining a block with refCnt=0
which is disallowed.
+ cacheable.retain();
+ return cacheable;
+ });
Review comment:
I am sure many of perf regressions reported in HBase 2 (compared to
HBase 1) in dev/user mailing lists related to read requests might be related to
using CHM#computeIfPresent usages for every onheap and offheap cache hits. Yes,
refCount makes code look better but on the other hand, we have perf issues.
I believe we should think about this and see if we really need netty based
refCount, or at least continue using CHM#get and ride over
`IllegalReferenceCountException` by swallowing it (I believe that's what
@ben-manes's suggestion is). And the final decision should be applicable to all
l1Cache strategies: SLRU, TinyLfu, AdaptiveLRU.
Otherwise BlockCache will have clear perf issues in HBase 1 vs HBase 2.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
