[
https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16418946#comment-16418946
]
Anastasia Braginsky commented on HBASE-20188:
---------------------------------------------
First, [~stack] thank you very much for doing this important performance
evaluation. It is so much valuable! Me and [~eshcar] are now going to join to
run the experiments, to let us see the bigger picture and to understand it
deeply, so we come to a wiser decisions.
Second, we must try with one segment in the pipeline
(hbase.hregion.compacting.pipeline.segments.limit=1). Because other than that
we actually have nothing to blame algorithmically in read-only scenario when
working with CompactingMemStore.
Last thing (and the most important one), I am looking on the read-only results
published by [~stack], and I am looking on *throughput* results; it goes as
following:
{code:java}
Old version HBase 1.2.7 = 86,915.48
HBase 2.0 = 37,816.69 <-- definitely dramatic
degradation
HBase 2.0 no CompactingMemStore = 73,487.67
HBase 2.0 no MSLAB = 81,321.40 <-- the best result for
HBase 2.0 !!!
HBase 2.0 no MSLAB no CompactingMemStore = 80,958.79 <-- still degradation
relatively to 1.2.7, maybe there is something more here that will change our
view on results?{code}
The first thing that jumps to my eyes is that when we take just MSLAB off we
get the best results... and latencies show the same. So we should at least
consider to take MSLAB out from default and not CompactingMemStore.
But most of all I would say that the experiments that we have so far are not
yet comprehensive enough to jump to the conclusions. There are not enough keys
written and for read-only workload we have 3-4 times more reads that didn't
found their keys then reads that found.
So again, bottom line, more experiments are needed and we are going to run
them. What about types of GC? GC configuration? CAM with MSLAB? I believe we
can allow ourselves to run the experiments 3-4 days more and to come to the
conclusion which is best for the HBase product.
> [TESTING] Performance
> ---------------------
>
> Key: HBASE-20188
> URL: https://issues.apache.org/jira/browse/HBASE-20188
> Project: HBase
> Issue Type: Umbrella
> Components: Performance
> Reporter: stack
> Priority: Blocker
> 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, 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,
> 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)
