[
https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16420874#comment-16420874
]
stack commented on HBASE-20188:
-------------------------------
bq. 31GB is a lot of heap. Is it that you start with single region and let it
split later?
Yeah, it is a lot but I was seeing that at 25M records, we were mostly going to
disk; the cache was not very effective (85%) or so. I could run w/ less if you
would prefer. Just say.
Yes, I start with a single region and let it split. This is how random
evaluators will run YCSB if I were to guess.
I posted GC times and incidence in the report. Will do so for the new runs. I
had to start over again because the workloada was reading from outside of the
loaded set so lots of reads of non-existent records. Trying to avoid that in
this run to make the compare less arbitrary.
bq. If you are sure CSM is the default GC for HBase 2.0 we should change our
settings accordingly.
It looks like this will be the case, yes. We've not done the work to flip to
G1GC.
bq. I would definitely suggest to try CellArrayMap (CAM) as default with MSLAB
and not CellChunkMap (CCM) as it is now.
Tell me how to config it and I'll try a run.
MSLAB is on by default in 2.0 until we do the long-range tests that show it not
needed for the various deploy scenarios.
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: 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)
