You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2013/01/20 17:30:13 UTC
[jira] [Commented] (HBASE-7631) 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:comment-tabpanel&focusedCommentId=13558305#comment-13558305 ]
stack commented on HBASE-7631:
------------------------------
I wonder if we are pulling fat rows if we shouldn't log it in regionserver logs... say, if the size is > 1MB/10MB... log detail on it (same as when slow query but that needs detail...)
> 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: Bug
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira