You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "dhruba borthakur (JIRA)" <ji...@apache.org> on 2011/03/14 09:07:29 UTC

[jira] Created: (HBASE-3632) ability to record the block cache hit ratio for the last few minutes

ability to record the block cache hit ratio for the last few minutes
--------------------------------------------------------------------

                 Key: HBASE-3632
                 URL: https://issues.apache.org/jira/browse/HBASE-3632
             Project: HBase
          Issue Type: Improvement
          Components: regionserver
            Reporter: dhruba borthakur
            Assignee: dhruba borthakur


In the curent code, the block cache hit ratio is calculated by using the total number of cache hits since the regin server was rebooted. This means that this metric does not reflect the short term changes that occur in the workload; the longer the region reserver is alive slower is the rate of change of this metric. 

I propose that this metric reflect the cache hit ratio for the work processed in the most recent 10 minutes, is that reasonable?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (HBASE-3632) ability to record the block cache hit ratio for the last few minutes

Posted by "Gary Helmling (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006572#comment-13006572 ] 

Gary Helmling commented on HBASE-3632:
--------------------------------------

This definitely makes sense to me, as a moving average seems a much more useful metric.  So seems like we'd want this for both "blockCacheHitRatio" and "blockCacheHitCachingRatio".

As an aside, we should probably not change the way that the related "count" metrics are reported though.  If a metrics collection setup is configured to see those as incrementing values, the displayed values freak out if they start reseting (I've seen this with cacti at least).

> ability to record the block cache hit ratio for the last few minutes
> --------------------------------------------------------------------
>
>                 Key: HBASE-3632
>                 URL: https://issues.apache.org/jira/browse/HBASE-3632
>             Project: HBase
>          Issue Type: Improvement
>          Components: regionserver
>            Reporter: dhruba borthakur
>            Assignee: dhruba borthakur
>
> In the curent code, the block cache hit ratio is calculated by using the total number of cache hits since the regin server was rebooted. This means that this metric does not reflect the short term changes that occur in the workload; the longer the region reserver is alive slower is the rate of change of this metric. 
> I propose that this metric reflect the cache hit ratio for the work processed in the most recent 10 minutes, is that reasonable?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (HBASE-3632) ability to record the block cache hit ratio for the last few minutes

Posted by "dhruba borthakur (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HBASE-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

dhruba borthakur resolved HBASE-3632.
-------------------------------------

    Resolution: Duplicate

Duplicate of HBASE-3306

> ability to record the block cache hit ratio for the last few minutes
> --------------------------------------------------------------------
>
>                 Key: HBASE-3632
>                 URL: https://issues.apache.org/jira/browse/HBASE-3632
>             Project: HBase
>          Issue Type: Improvement
>          Components: regionserver
>            Reporter: dhruba borthakur
>            Assignee: dhruba borthakur
>
> In the curent code, the block cache hit ratio is calculated by using the total number of cache hits since the regin server was rebooted. This means that this metric does not reflect the short term changes that occur in the workload; the longer the region reserver is alive slower is the rate of change of this metric. 
> I propose that this metric reflect the cache hit ratio for the work processed in the most recent 10 minutes, is that reasonable?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (HBASE-3632) ability to record the block cache hit ratio for the last few minutes

Posted by "stack (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006628#comment-13006628 ] 

stack commented on HBASE-3632:
------------------------------

@Todd You talking about displaying graphs using jrobin?  (Seems like its *GPL though -- dang)

> ability to record the block cache hit ratio for the last few minutes
> --------------------------------------------------------------------
>
>                 Key: HBASE-3632
>                 URL: https://issues.apache.org/jira/browse/HBASE-3632
>             Project: HBase
>          Issue Type: Improvement
>          Components: regionserver
>            Reporter: dhruba borthakur
>            Assignee: dhruba borthakur
>
> In the curent code, the block cache hit ratio is calculated by using the total number of cache hits since the regin server was rebooted. This means that this metric does not reflect the short term changes that occur in the workload; the longer the region reserver is alive slower is the rate of change of this metric. 
> I propose that this metric reflect the cache hit ratio for the work processed in the most recent 10 minutes, is that reasonable?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (HBASE-3632) ability to record the block cache hit ratio for the last few minutes

Posted by "Jean-Daniel Cryans (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006590#comment-13006590 ] 

Jean-Daniel Cryans commented on HBASE-3632:
-------------------------------------------

+1 what Gary said.

> ability to record the block cache hit ratio for the last few minutes
> --------------------------------------------------------------------
>
>                 Key: HBASE-3632
>                 URL: https://issues.apache.org/jira/browse/HBASE-3632
>             Project: HBase
>          Issue Type: Improvement
>          Components: regionserver
>            Reporter: dhruba borthakur
>            Assignee: dhruba borthakur
>
> In the curent code, the block cache hit ratio is calculated by using the total number of cache hits since the regin server was rebooted. This means that this metric does not reflect the short term changes that occur in the workload; the longer the region reserver is alive slower is the rate of change of this metric. 
> I propose that this metric reflect the cache hit ratio for the work processed in the most recent 10 minutes, is that reasonable?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (HBASE-3632) ability to record the block cache hit ratio for the last few minutes

Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006609#comment-13006609 ] 

Todd Lipcon commented on HBASE-3632:
------------------------------------

Might be interesting to consider using something like jrobin for metrics like this - so we can get these metrics at various granularities.

> ability to record the block cache hit ratio for the last few minutes
> --------------------------------------------------------------------
>
>                 Key: HBASE-3632
>                 URL: https://issues.apache.org/jira/browse/HBASE-3632
>             Project: HBase
>          Issue Type: Improvement
>          Components: regionserver
>            Reporter: dhruba borthakur
>            Assignee: dhruba borthakur
>
> In the curent code, the block cache hit ratio is calculated by using the total number of cache hits since the regin server was rebooted. This means that this metric does not reflect the short term changes that occur in the workload; the longer the region reserver is alive slower is the rate of change of this metric. 
> I propose that this metric reflect the cache hit ratio for the work processed in the most recent 10 minutes, is that reasonable?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (HBASE-3632) ability to record the block cache hit ratio for the last few minutes

Posted by "Jonathan Gray (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006613#comment-13006613 ] 

Jonathan Gray commented on HBASE-3632:
--------------------------------------

This is basically what is implemented over in HBASE-3306.  Just needs to be finished.

I can try to work on this over the next couple days.

> ability to record the block cache hit ratio for the last few minutes
> --------------------------------------------------------------------
>
>                 Key: HBASE-3632
>                 URL: https://issues.apache.org/jira/browse/HBASE-3632
>             Project: HBase
>          Issue Type: Improvement
>          Components: regionserver
>            Reporter: dhruba borthakur
>            Assignee: dhruba borthakur
>
> In the curent code, the block cache hit ratio is calculated by using the total number of cache hits since the regin server was rebooted. This means that this metric does not reflect the short term changes that occur in the workload; the longer the region reserver is alive slower is the rate of change of this metric. 
> I propose that this metric reflect the cache hit ratio for the work processed in the most recent 10 minutes, is that reasonable?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (HBASE-3632) ability to record the block cache hit ratio for the last few minutes

Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006639#comment-13006639 ] 

Todd Lipcon commented on HBASE-3632:
------------------------------------

ah, I didn't realize it was LGPL. bummer. jfreechart's nice too, but also LGPL.

> ability to record the block cache hit ratio for the last few minutes
> --------------------------------------------------------------------
>
>                 Key: HBASE-3632
>                 URL: https://issues.apache.org/jira/browse/HBASE-3632
>             Project: HBase
>          Issue Type: Improvement
>          Components: regionserver
>            Reporter: dhruba borthakur
>            Assignee: dhruba borthakur
>
> In the curent code, the block cache hit ratio is calculated by using the total number of cache hits since the regin server was rebooted. This means that this metric does not reflect the short term changes that occur in the workload; the longer the region reserver is alive slower is the rate of change of this metric. 
> I propose that this metric reflect the cache hit ratio for the work processed in the most recent 10 minutes, is that reasonable?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira