hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Otis Gospodnetic (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4147) StoreFile query usage report
Date Wed, 14 Sep 2011 16:27:09 GMT

    [ https://issues.apache.org/jira/browse/HBASE-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104623#comment-13104623
] 

Otis Gospodnetic commented on HBASE-4147:
-----------------------------------------

+1 for Todd's tracing idea (is this already in a separate JIRA issue that I can't find?)
+1 for what Gary said about using existing mechanisms for publishing metrics, so that those
of us who already have tools to gather and aggregate data from there can just keep using those
tools instead of developing new things that scrape metrics from additional places.


> StoreFile query usage report
> ----------------------------
>
>                 Key: HBASE-4147
>                 URL: https://issues.apache.org/jira/browse/HBASE-4147
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Doug Meil
>            Priority: Minor
>         Attachments: hbase_4147_storefilereport.pdf, hbase_4147_storefilereport_2011_08_10.pdf
>
>
> Detailed information on what HBase is doing in terms of reads is hard to come by.
> What would be useful is to have a periodic StoreFile query report.  Specifically, this
could run on a configured interval (e.g., every 30 seconds, 60 seconds) and dump the output
to the log files.
> This would have all StoreFiles accessed during the reporting period (and with the Path
we would also know region, CF, and table), # of times the StoreFile was accessed, the size
of the StoreFile, and the total time (ms) spent processing that StoreFile.
> Even this level of summary would be useful to detect a which tables & CFs are being
accessed the most, and including the StoreFile would provide insight into relative "uncompaction"
(i.e., lots of StoreFiles).
> I think the log-output, as opposed to UI, is an important facet with this.  I'm assuming
that users will slice and dice this data on their own so I think we should skip any kind of
admin view for now (i.e., new JSPs, new APIs to expose this data).  Just getting this to log-file
would be a big improvement.
> Will this have a non-zero performance impact?  Yes.  Hopefully small, but yes it will.
 However, flying a plane without any instrumentation isn't fun.  :-)  
>  

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

        

Mime
View raw message