[
https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421327#comment-16421327
]
Anastasia Braginsky commented on HBASE-20188:
---------------------------------------------
Looking on the recent results (got to the same conclusions as [~stack]):
# As expected due to big heap, we see almost no difference due to
CompactingMemStore. Still CompactingMemStore (with factor 0.1 or 0.02) perform
better than NONE (in all workloads), but just slightly better. However, setting
in-memory-flush factor to 2% makes it better, we should keep it as default I
think.
# We have huge gap in read-only performance between old HBase and all variants
of MemStore in HBase 2.0. This is a big deal... we should look somewhere else
for the reason.
# As I said, due to understanding that MSLAB and CMS GC is going to be
default, we should try MSLAB with CAM index. The patch to enable this config is
provided and we will try it ourselves as well.
# I think we can also try setting in-memory-flush factor to 2% and one segment
in the pipeline.
# There was a line "Return=NOT_FOUND" in previous results, now this line is
missing. Is it because there is no such reads, or just missing the line?
Bottom line, the biggest performance problem for now is the strong read
performance degradation and it looks like this is not due to MemStore change.
We should all concentrate on that. Any ideas? Could it be something in MVCC?
Concurrency control (locks)? Missing reads? Slower reading from the disk/cache
for some reason?
> [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, 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)
