[
https://issues.apache.org/jira/browse/HBASE-13291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14390134#comment-14390134
]
ramkrishna.s.vasudevan commented on HBASE-13291:
------------------------------------------------
bq.For now can we just add it on a per file level and have the Reader remember
if it ever needs to read a tag.
At the store scanner level not sure how easy it would be to make this.
StoreScanner I think would only deal with the cells that it has. Can check once
if it is possible, then that would be better. We have the Hfilecontext and we
could see if we can get information from that upto this StoreScanner level.
> 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: 13291.hacks.txt, 13291.inlining.txt, Screen Shot
> 2015-03-26 at 12.12.13 PM.png, Screen Shot 2015-03-26 at 3.39.33 PM.png,
> hack_to_bypass_bb.txt, nonBBposAndInineMvccVint.txt, q (1).png, traces.7.svg,
> traces.filterall.svg, traces.nofilter.svg, traces.small2.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)
