[
https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408991#comment-16408991
]
stack edited comment on HBASE-20188 at 3/22/18 4:17 AM:
--------------------------------------------------------
h2. HBase1 vs HBase2
h3. ITBLL 2.5B, 6 RegionServers
I ran a 2.5B ITBLL against 7 node cluster with NO chaos, first against 1.2.7,
then against branch-2.0 tip. Same default configs in both cases (16G heaps).
First ITBLL Generate (Random Writes) and then Verify (Reads). HBase2 completed
in less time using less CPU and GC. Less memstore used too (the in-memory
compaction segments won't show because no metrics exposed). Looking at graphs,
hbase2 runs smoother than hbase1; less erratic fluctuation in reads and writes
(The Master UI must have changed how it accounts operations because hbase1
shows 100k ops/second where hbase2 shows hundreds of ops a second). When hbase1
was running MR tasks were all RegionTooBusyExceptions. I didn't check hbase2
but I did check the metrics for RegionTooBusy and it said zero (This metric
seems broke on branch-1). See attached graphs. Let me do straight YCSB next.
was (Author: stack):
h2. HBase1 vs HBase2
I ran a 2.5B ITBLL against 7 node cluster with NO chaos, first against 1.2.7,
then against branch-2.0 tip. Same default configs in both cases (16G heaps).
First ITBLL Generate (Random Writes) and then Verify (Reads). HBase2 completed
in less time using less CPU and GC. Less memstore used too (the in-memory
compaction segments won't show because no metrics exposed). Looking at graphs,
hbase2 runs smoother than hbase1; less erratic fluctuation in reads and writes
(The Master UI must have changed how it accounts operations because hbase1
shows 100k ops/second where hbase2 shows hundreds of ops a second). When hbase1
was running MR tasks were all RegionTooBusyExceptions. I didn't check hbase2
but I did check the metrics for RegionTooBusy and it said zero (This metric
seems broke on branch-1). See attached graphs. Let me do straight YCSB next.
> [TESTING] Performance
> ---------------------
>
> Key: HBASE-20188
> URL: https://issues.apache.org/jira/browse/HBASE-20188
> Project: HBase
> Issue Type: Umbrella
> Components: Performance
> Reporter: stack
> Priority: Critical
> Fix For: 2.0.0
>
> Attachments: 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, flamegraph-1072.1.svg,
> flamegraph-1072.2.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)
