phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse Yates (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-177) Collect usage and performance metrics
Date Mon, 04 Aug 2014 18:08:15 GMT

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

Jesse Yates commented on PHOENIX-177:
-------------------------------------

Well, there is no support for sinks in Hadoop1 (yet). As long as its working against hadoop2,
I'm not too concerned about the exact error being thrown in hadoop1

> Collect usage and performance metrics
> -------------------------------------
>
>                 Key: PHOENIX-177
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-177
>             Project: Phoenix
>          Issue Type: Sub-task
>    Affects Versions: 5.0.0, 4.1
>            Reporter: ryang-sfdc
>            Assignee: Jesse Yates
>              Labels: enhancement
>             Fix For: 5.0.0, 4.1
>
>         Attachments: phoenix-177-4.0.patch, phoenix-177-master-v0.patch, phoenix-177-master.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)

Mime
View raw message