[
https://issues.apache.org/jira/browse/HBASE-13291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-13291:
--------------------------
Attachment: traces.7.svg
13291.inlining.txt
Patch breaks up methods that were not being inlined or complaint was that they
were 'too big'. Adds 'final' on methods though all I read has it that this
makes no difference.
See our flame graph that has all below ScannerV2.next inlined. Compare to the
filterall.svg graph initially posted. Now with inlining we are using 29% of CPU
doing ScannerV2.next. Previous we were doing 36% plus.
Here are args passed JVM:
export HBASE_OPTS="
-agentpath:/home/stack/lightweight-java-profiler-read-only/build-64/liblagent.so
-XX:+UseConcMarkSweepGC -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining
-XX:+PrintCompilation -XX:+UnlockCommercialFeatures -XX:+FlightRecorder "
> 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.inlining.txt, traces.7.svg, 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)
