You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2015/01/12 19:32:35 UTC

[jira] [Resolved] (HBASE-7631) Per Region read/write sizes in metrics (WAS: Region w/ few, fat reads was hard to find on a box carrying hundreds of regions)

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

stack resolved HBASE-7631.
--------------------------
    Resolution: Not a Problem

We have basic per-region metrics now. Resolving as 'not-a-problem'.  Thanks [~clehene] for the kick.

> Per Region read/write sizes in metrics (WAS: Region w/ few, fat reads was hard to find on a box carrying hundreds of regions)
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-7631
>                 URL: https://issues.apache.org/jira/browse/HBASE-7631
>             Project: HBase
>          Issue Type: Improvement
>          Components: metrics
>            Reporter: stack
>
> Of a sudden on a prod cluster, a table's rows gained girth... hundreds of thousands of rows... and the application was pulling them all back every time but only once a second or so.  Regionserver was carrying hundreds of regions.  Was plain that there was lots of network out traffic.  It was tough figuring which region was the culprit (JD's trick was moving the regions off one at a time while watching network out traffic on cluster to see whose spiked next -- it worked but just some time).
> If we had per region read/write sizes in metrics, that would have saved a bunch of diagnostic time.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)