[jira] [Comment Edited] (PHOENIX-1906) With large number of guideposts, queries that iterate over a small range gets starved when running concurrently with larger queries

["ramkrishna.s.vasudevan (JIRA)" <ji...@apache.org>]

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

ramkrishna.s.vasudevan edited comment on PHOENIX-1906 at 4/22/15 6:24 AM:
--------------------------------------------------------------------------

[~giacomotaylor]
I understand the real case here.  It is probably better to highlight this in the HBase community through that JIRA. Let me do that.  I have updated a patch there in HBASE-12790 after testing in a real cluster environment.  Some interesting bug was found and fixed.
As I said the only problem that I face is to write a real time test case, which I am figuring out a way probably that would work.


was (Author: ram_krish):
[~giacomotaylor]
I understand the real case here.  It is probably better to highlight this in the HBase community through that JIRA. Let me do that.  I have updated a patch there in HBASE-12790 after testing in a real cluster environment.  Some interesting bug was found and fixed.
As I said the only problem that I face is to write a real time test case, which I am figuring out a way probably that would worm.

> With large number of guideposts, queries that iterate over a small range gets starved when running concurrently with larger queries
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-1906
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1906
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Mujtaba Chohan
>
> Consider the scenario with a single region server. Table has 500 guide posts (data is large enough that it won't fit either into HBase block or OS page cache so it gets blocked on disk I/O during scans) and running the following 2 queries concurrently with and without stats enabled:
> {code}select count(*) from table{code}
> {code}select * from table limit 10{code}
> With stats *disabled*, average time for these two queries is 100sec and 100ms respectively. However with stats long running count aggregate query time drops to 8 second but limit query time increases to 3 seconds. Degradation in limit query time is even more evident when concurrency level is further increased.
> [~jamestaylor]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)