[
https://issues.apache.org/jira/browse/PHOENIX-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Yates updated PHOENIX-177:
--------------------------------
Attachment: phoenix-177-master-v0.patch
Attaching patch for master, probably pretty close (if not exactly) what would
be used for 4.X. Also, more easily parsed code can be seen [on
github|https://github.com/jyates/phoenix/tree/tracing] - I can do a pull
request for easier review if people want as well.
For an overview, like my original proposal, it uses HTrace to generate spans
(segments of work, which may or may not have children) which are then written
to the metrics2 framework. The framework then has a receiver (only Hadoop2
supported at the moment) which writes them to a phoenix table. All the these
different pipes can be configured to be more specialized, depending on the use
case/need.
FYI [~jamestaylor]
> Collect usage and performance metrics
> -------------------------------------
>
> Key: PHOENIX-177
> URL: https://issues.apache.org/jira/browse/PHOENIX-177
> Project: Phoenix
> Issue Type: Task
> Affects Versions: 5.0.0, 4.1
> Reporter: ryang-sfdc
> Assignee: Jesse Yates
> Labels: enhancement
> Attachments: phoenix-177-master-v0.patch
>
>
> I'd like to know how much cpu, physical io, logical io, wait time, blocking
> time, transmission time was spent for each thread of execution across the
> hbase cluster, within coprocessors, and within the client's phoenix
> threadpools for each query.
> Here are some of the problems I want to solve:
> 1) every component has one or more configurable threadpools, and I have no
> idea how to gather data to make any decisions.
> 2) queries that I think should be fast turn out to be dog slow, e.g., select
> foo from bar where foo like 'abc%' group by foo Without attaching a profiler
> to hbase, which most people won't bother with, it's not clear why it's slow.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
