[
https://issues.apache.org/jira/browse/HBASE-5292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202026#comment-13202026
]
Phabricator commented on HBASE-5292:
------------------------------------
mbautin has commented on the revision "[jira] [HBASE-5292] [89-fb] Prevent
counting getSize on compactions".
@zhiqiu: does this problem exist in the open-source HBase trunk? If so, could
you please port this patch to trunk? If this is not applicable to trunk, could
you please set the JIRA status to "resolved"? Thanks!
REVISION DETAIL
https://reviews.facebook.net/D1527
> getsize per-CF metric incorrectly counts compaction related reads as well
> --------------------------------------------------------------------------
>
> Key: HBASE-5292
> URL: https://issues.apache.org/jira/browse/HBASE-5292
> Project: HBase
> Issue Type: Bug
> Reporter: Kannan Muthukkaruppan
> Attachments: D1527.1.patch, D1527.2.patch, D1527.3.patch,
> D1527.4.patch
>
>
> The per-CF "getsize" metric's intent was to track bytes returned (to HBase
> clients) per-CF. [Note: We already have metrics to track # of HFileBlock's
> read for compaction vs. non-compaction cases -- e.g., compactionblockreadcnt
> vs. fsblockreadcnt.]
> Currently, the "getsize" metric gets updated for both client initiated
> Get/Scan operations as well for compaction related reads. The metric is
> updated in StoreScanner.java:next() when the Scan query matcher returns an
> INCLUDE* code via a:
> HRegion.incrNumericMetric(this.metricNameGetsize, copyKv.getLength());
> We should not do the above in case of compactions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
