You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Samarth Jain (JIRA)" <ji...@apache.org> on 2015/02/26 02:28:05 UTC
[jira] [Updated] (PHOENIX-1452) Add Phoenix client-side logging and
capture resource utilization metrics
[ https://issues.apache.org/jira/browse/PHOENIX-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Samarth Jain updated PHOENIX-1452:
----------------------------------
Attachment: wip.patch
Initial work in progress patch that exposes the following global metrics:
1) Number of scans executed - min/max/avg/count.
2) Number of mutations - min/max/avg/count.
3) Number of spool files created - count.
4) Query duration - min/max/avg/count.
5) Commit duration - min/max/avg/count.
6) Number of times query timed out - count.
7) Bytes requested from GlobalMemoryManager - min/max/avg/count.
8) Wait times for memory to be allocated - min/max/avg/count.
These metrics are being exposed through a method in PhoenixRuntime.
[~jamestaylor] [~jfernando_sfdc] - please review and see if the approach I have taken makes sense. Thanks!
> Add Phoenix client-side logging and capture resource utilization metrics
> ------------------------------------------------------------------------
>
> Key: PHOENIX-1452
> URL: https://issues.apache.org/jira/browse/PHOENIX-1452
> Project: Phoenix
> Issue Type: Improvement
> Affects Versions: 5.0.0, 4.2
> Reporter: Jan Fernando
> Assignee: Samarth Jain
> Attachments: wip.patch
>
>
> For performance testing and tuning of features that use Phoenix and for production monitoring it would be really helpful to easily be able to extract statistics about Phoenix's client-side Thread Pool and Queue Depth usage to help with tuning and being able to correlate the impact of tuning these 2 parameters to query performance.
> For global per JVM logging one of the following would meet my needs, with a preference for #2:
> 1. A simple log line that that logs the data in ThreadPoolExecutor.toString() at a configurable interval
> 2. Exposing the ThreadPoolExecutor metrics in PhoenixRuntime or other global client exposed class and allow client to do their own logging.
> In addition to this it would also be really valuable to have a single log line per query that provides statistics about the level of parallelism i.e. number of parallel scans being executed. I don't full explain plan level of data but a good heuristic to be able to track over time how queries are utilizing the thread pool as data size grows etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)