[
https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16424894#comment-16424894
]
stack commented on HBASE-20188:
-------------------------------
Fixing short-circuit reads config made a big difference to hbase2 read
throughput putting it close to hbase-1.2.7. Let me update the report. hbase1
seemed fine with having shortcircuit reads = true but hbase2 was complaining
falling back on remote reads. The giveaway was the differing lock profiles. See
attached locking profile flamegraph lock.127.workloadc.20180402T200918Z.svg for
1.2.7 workloadc. Notice how we are blocking on the ShortCircuitCache cache
inside in *local* BlockReader.
A run against hbase2 with same configurations had the locking profile
lock.2.memsize2.c.20180403T160257Z.svg. There are a few things going on but we
are sticking on PeerCache from *remote* BlockReader. Looking in hbase2
regionserver logs, it seems like we ran fine for a while and then the
shortcircuit cache would throw exceptions and hold up the handler a while. Our
doc on short-circuit setup is stale. Updated it here HBASE-20337
> [TESTING] Performance
> ---------------------
>
> Key: HBASE-20188
> URL: https://issues.apache.org/jira/browse/HBASE-20188
> Project: HBase
> Issue Type: Umbrella
> Components: Performance
> Reporter: stack
> Assignee: stack
> Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: CAM-CONFIG-V01.patch, HBASE-20188.sh, HBase 2.0
> performance evaluation - Basic vs None_ system settings.pdf,
> ITBLL2.5B_1.2.7vs2.0.0_cpu.png, ITBLL2.5B_1.2.7vs2.0.0_gctime.png,
> ITBLL2.5B_1.2.7vs2.0.0_iops.png, ITBLL2.5B_1.2.7vs2.0.0_load.png,
> ITBLL2.5B_1.2.7vs2.0.0_memheap.png, ITBLL2.5B_1.2.7vs2.0.0_memstore.png,
> ITBLL2.5B_1.2.7vs2.0.0_ops.png,
> ITBLL2.5B_1.2.7vs2.0.0_ops_NOT_summing_regions.png, YCSB_CPU.png,
> YCSB_GC_TIME.png, YCSB_IN_MEMORY_COMPACTION=NONE.ops.png, YCSB_MEMSTORE.png,
> YCSB_OPs.png, YCSB_in-memory-compaction=NONE.ops.png, YCSB_load.png,
> cpu.127.workloadc.20180402T200918Z.svg,
> cpu.127.workloadc.20180402T200918Z.svg, flamegraph-1072.1.svg,
> flamegraph-1072.2.svg, lock.2.memsize2.c.20180403T160257Z.svg,
> misses.127.workloadc.20180402T200918Z.svg, tree.txt
>
>
> How does 2.0.0 compare to old versions? Is it faster, slower? There is rumor
> that it is much slower, that the problem is the asyncwal writing. Does
> in-memory compaction slow us down or speed us up? What happens when you
> enable offheaping?
> Keep notes here in this umbrella issue. Need to be able to say something
> about perf when 2.0.0 ships.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
