[jira] [Comment Edited] (HBASE-20188) [TESTING] Performance

["stack (JIRA)" <ji...@apache.org>]

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

stack edited comment on HBASE-20188 at 4/4/18 2:24 AM:
-------------------------------------------------------

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. Here is hbase1's locking profile for workloadc looked like:

 [^lock.127.workloadc.20180402T200918Z.svg] 

Notice how we are blocking on the ShortCircuitCache cache inside in *local* BlockReader.

A run against hbase2 with same configurations had this locking profile:

 [^cpu.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


was (Author: stack):
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. Here is hbase1's locking profile for workloadc looked like:

 [^misses.127.workloadc.20180402T200918Z.svg] 

Notice how we are blocking on the ShortCircuitCache cache inside in *local* BlockReader.

A run against hbase2 with same configurations had this locking profile:

 [^cpu.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.2.memsize2.c.20180403T160257Z.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)