You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Bryan Beaudreault (Jira)" <ji...@apache.org> on 2022/09/23 18:32:00 UTC

[jira] [Updated] (HBASE-27241) Add metrics for evaluating cost and effectiveness of bloom filters

     [ https://issues.apache.org/jira/browse/HBASE-27241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryan Beaudreault updated HBASE-27241:
--------------------------------------
    Fix Version/s: 2.5.0
                       (was: 2.5.1)

> Add metrics for evaluating cost and effectiveness of bloom filters
> ------------------------------------------------------------------
>
>                 Key: HBASE-27241
>                 URL: https://issues.apache.org/jira/browse/HBASE-27241
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Bryan Beaudreault
>            Assignee: Bryan Beaudreault
>            Priority: Major
>              Labels: patch-available
>             Fix For: 2.5.0, 3.0.0-alpha-4
>
>
> Bloom filters can be costly for some tables, easily resulting in an aggregate memory footprint of many GBs. It's currently hard to monitor for that cost on a per-table basis. You can view {{staticBloomSize}} in JMX, but that is for the whole server. Otherwise you must manually sum the values using the regionserver UI.  We can add this (as well as staticIndexSize) to the per-table metrics.
> Additionally, it can be hard to know how effective those bloom filters are. I think the easiest way to measure that is to count bloomFilterRequests and bloomFilterNegativeResults. With these metrics in hand, one can have an easier time deciding how much memory they want to give to their L1 cache and/or whether they want to disable blooms on a table.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)