[
https://issues.apache.org/jira/browse/HBASE-30394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huginn updated HBASE-30394:
---------------------------
Description:
## What happens
TinyLfuBlockCache reports the aggregate cache size and entry count as data
block size and count, so the data-block statistics include index and metadata
blocks.
## When it happens
This occurs when TinyLfuBlockCache contains a mixture of data, index, or
metadata blocks and callers query getCurrentDataSize() or getDataBlockCount().
## Impact
The reported data block size and count are inaccurate, which can make cache
composition and capacity analysis misleading.
## Root cause
In TinyLfuBlockCache, getCurrentDataSize() returns getCurrentSize() and
getDataBlockCount() returns getBlockCount(). The insertion and eviction paths
do not maintain separate data-block counters.
## Proposed fix
Track the size and count of data blocks separately during cache insertion and
removal, updating the counters only for blocks whose BlockType is data.
## Reproduction
Testing evidence will be added by the reporter.
was:
## What happens
TinyLfuBlockCache reports aggregate cache size and block count through
getCurrentDataSize() and getDataBlockCount(), even though these APIs are
intended to report data-block-only statistics. As a result, data-block metrics
are indistinguishable from aggregate cache metrics when index or metadata
blocks are cached.
## When it happens
This occurs when TinyLfuBlockCache is used and the cache contains a mixture of
data, index, or metadata blocks. The current implementation derives both values
from the aggregate Caffeine cache size and entry count.
## Impact
Operators and monitoring cannot accurately determine the amount and number of
data blocks held by TinyLfuBlockCache, which can make cache composition and
capacity analysis misleading.
## Root cause
On master, TinyLfuBlockCache.getCurrentDataSize() returns getCurrentSize() and
getDataBlockCount() returns getBlockCount(). The insertion and eviction paths
do not maintain separate data-block counters, so the implementation cannot
satisfy the data-block-specific BlockCache contract.
<!-- File:
hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/TinyLfuBlockCache.java,
upstream master -->
<!-- Lines: 185-197, 226-232, 296-317, 412-419 -->
## Proposed fix
Maintain the current data-block size and count while blocks are inserted and
removed. Update the counters only for blocks whose BlockType is data, and
return those counters from getCurrentDataSize() and getDataBlockCount().
## Reproduction
Testing evidence will be added by the reporter.
> Report data block size and count separately in TinyLfuBlockCache
> ----------------------------------------------------------------
>
> Key: HBASE-30394
> URL: https://issues.apache.org/jira/browse/HBASE-30394
> Project: HBase
> Issue Type: Bug
> Components: BlockCache
> Affects Versions: 2.4.11
> Reporter: huginn
> Priority: Major
> Labels: pull-request-available
>
> ## What happens
> TinyLfuBlockCache reports the aggregate cache size and entry count as data
> block size and count, so the data-block statistics include index and metadata
> blocks.
> ## When it happens
> This occurs when TinyLfuBlockCache contains a mixture of data, index, or
> metadata blocks and callers query getCurrentDataSize() or getDataBlockCount().
> ## Impact
> The reported data block size and count are inaccurate, which can make cache
> composition and capacity analysis misleading.
> ## Root cause
> In TinyLfuBlockCache, getCurrentDataSize() returns getCurrentSize() and
> getDataBlockCount() returns getBlockCount(). The insertion and eviction paths
> do not maintain separate data-block counters.
> ## Proposed fix
> Track the size and count of data blocks separately during cache insertion and
> removal, updating the counters only for blocks whose BlockType is data.
> ## Reproduction
> Testing evidence will be added by the reporter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
