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

ramkrishna.s.vasudevan commented on HBASE-13291:
------------------------------------------------

@Stack
The --fitlerAll property has a filterKeyValue() returning SKIP.  This means 
that we would endup in removing all the rows in the SQM layer itself. 
If we make the filterKeyValue return INCLUDE then we will end up coming till 
the HRegion layer. Anyway there filterRow will filter out the results.  May be 
can you try changing that and see if there is a little bit of difference in 
that?

> Lift the scan ceiling
> ---------------------
>
>                 Key: HBASE-13291
>                 URL: https://issues.apache.org/jira/browse/HBASE-13291
>             Project: HBase
>          Issue Type: Improvement
>          Components: Scanners
>    Affects Versions: 1.0.0
>            Reporter: stack
>            Assignee: stack
>         Attachments: traces.filterall.svg, traces.nofilter.svg, 
> traces.smaller.svg
>
>
> Scanning medium sized rows with multiple concurrent scanners exhibits 
> interesting 'ceiling' properties. A server runs at about 6.7k ops a second 
> using 450% of possible 1600% of CPUs  when 4 clients each with 10 threads 
> doing scan 1000 rows.  If I add '--filterAll' argument (do not return 
> results), then we run at 1450% of possible 1600% possible but we do 8k ops a 
> second.
> Let me attach flame graphs for two cases. Unfortunately, there is some 
> frustrating dark art going on. Let me try figure it... Filing issue in 
> meantime to keep score in.



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

Reply via email to