[
https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16413186#comment-16413186
]
stack commented on HBASE-20188:
-------------------------------
[~anastas] Sorry. Should have been better w/ how to decode the graph. Look at
the 'YCSB_IN_MEMORY_COMPACTION%3DNONE.ops.png' graph.
The YCSB run is made up of 4 back-to-back runs. There is the load phase, then a
50/50 phase, then the 95% reads phase, and finally the 80% writes phase. Each
phase lasts 20 minutes. If you look at the graph, there are four 'runs' each of
4 phases. The first run is an hbase 1.2.7 run. The second run is 2.0.0. The
third run is me thinking I had disabled in-memory compaction by setting
hbase-site.xml to NONE and fourth is me setting the property on the table so it
was off.
bq. ...if you say that turning in-memory-compaction off doesn't improve the
reads we should look for the source for reads degradation anywhere else.
Yes. On it.
[~eshcar]
bq. Can you give the same table with the none numbers?
I will. I'll be back w/ the numbers. I'll post 50th and 99th too.
bq. I ran them with CAM setting and no mslab.
Pass me the settings you would have me try and I'll try them here to see if a
difference. Sorry for stating the obvious but we run w/ MSLAB to avoid OOMEs
because of heap fragmentation brought on by CSLM. If we were to turn it off,
we'd have to do some legwork to ensure that we don't bring back the old OOMEs.
Thanks.
bq. This doesn't make much sense. If we flush "only" after aggregating 10% of
the data in the active segment we can use a pipeline of length 1, this would be
equivalent to a longer pipeline (of length 4) with smaller segments (consisting
of 2% of the data).
Ugh. sorry. I don't get it. I'm confused. Setting pipeline length to 1 but the
pipeline would be longer.... Sorry for being thick. Tell me what to try. Would
be good to get good defaults in now rather than later. Thanks.
I looked at the blogs, old talks and at old issue Release Notes. Is there a
paragraph write-up somewhere of what finally made it into hbase2 and the
configurations an operator can twiddle? I'd like to surface something up into
the refguide; e.g. default if MSLAB is... if w/o MSLAB its CAM, etc. I can find
beautiful pictures and definitions but a summary by one of you two experts
would help -- even if it was just pointers that'd be enough. Thanks.
> [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, 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)
