[
https://issues.apache.org/jira/browse/HBASE-15134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15455307#comment-15455307
]
Abhishek Singh Chouhan commented on HBASE-15134:
------------------------------------------------
[~eclark] [~anoopsamjohn] Does this patch looks heading in the right direction?
I thought about adding a metric to keep a track of the max too but the only
possibilities looked either to have it in
"org.apache.hadoop.hbase.regionserver.MetricsRegionWrapperImpl.HRegionMetricsWrapperRunnable"
in which case it might not report correctly since its run at an interval of 45
seconds by which time we might have hit max queue count and cleared off too.
Other seemed doing a check everytime a request is queued against a prev max but
this would also have to be synchronized (not very sure if thats a good idea).
Any thoughts ?
> Add visibility into Flush and Compaction queues
> -----------------------------------------------
>
> Key: HBASE-15134
> URL: https://issues.apache.org/jira/browse/HBASE-15134
> Project: HBase
> Issue Type: New Feature
> Reporter: Elliott Clark
> Attachments: HBASE-15134.patch, HBASE-15134.patch
>
>
> On busy spurts we can see regionservers start to see large queues for
> compaction. It's really hard to tell if the server is queueing a lot of
> compactions for the same region, lots of compactions for lots of regions, or
> just falling behind.
> For flushes much the same. There can be flushes in queue that aren't being
> run because of delayed flushes. There's no way to know from the metrics how
> many flushes are for each region, how many are delayed. Etc.
> We should add either more metrics around this ( num per region, max per
> region, min per region ) or add on a UI page that has the list of compactions
> and flushes.
> Or both.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
