[
https://issues.apache.org/jira/browse/HBASE-27570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17682687#comment-17682687
]
Bryan Beaudreault commented on HBASE-27570:
-------------------------------------------
I updated the title and description to simplify a bit. My main goal here is to
have consistent block IO accounting across request types. My original idea for
how to do this was to use ScannerContext. Since all reads eventually get down
into RegionScannerImpl, it seemed to make sense. Actually plumbing
ScannerContext into all levels ends up getting pretty involved, and the main
responsibility of ScannerContext is to enforce scan limits.
So now I'm going to instead try going with the simpler solution of calling
RpcCall.incrementResponseBlockSize in the StoreScanner.
> Unify tracking of block IO across all read request types
> --------------------------------------------------------
>
> Key: HBASE-27570
> URL: https://issues.apache.org/jira/browse/HBASE-27570
> Project: HBase
> Issue Type: Improvement
> Reporter: Bryan Beaudreault
> Priority: Major
>
> Various requests in RSRpcServices use
> [addSize|https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java#L1303-L1335]
> in an attempt to estimate block IO of the request by pulling the capacity of
> the underlying cell buffer when that buffer changes. This is just an estimate
> and can be inaccurate in certain circumstances, such as when the ordering of
> gets in a multiget causes the same buffer to be counted twice.
> As of HBASE-27558, we now have a hook in StoreScanner for tracking block IO
> via HFileReaderImpl.reportBlockSize method call. We use this for getting
> block IO into ScannerContext for tracking limits. We can add a call to
> RpcCall.incrementResponseBlockSize here so that we can get an accurate
> accounting of block IO for all request types.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
