[
https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16405099#comment-16405099
]
stack commented on HBASE-20188:
-------------------------------
Yeah, sorry if messed up the focus of this issue. This issue is about
addressing the rumors that 2.0 is slower than 1.x (as [~carp84] reminds us). I
dumped in here some questions around CMS (Compacting MemStore) because I'm
running some scale tests and want them to finish faster... ; we used to block
writing when we hit global or store limits; now we instead throw a
RegionTooBusyExceptions back to the client -- sometimes the MR tasks spend a
long time hanging out cycling through RegionTooBusyExceptions (We don't seem to
be blocking because we've hit the global limit which is good...).
Let me answer some comments in the above.
[~eshcar] Do you pre-split the regions before the test?
No. I'm running the ITBLL test. It starts with clean table of one region. We
want to include testing we do not lose data across splits. FYI.
bq. Can you estimate the rate at which the test is writing, what is the
throughput? what is the data size written at each operation?
Smile. Good questions.
Let me do a compare to 1.4.
bq. To check if this is indeed the problem you can decrease
hbase.hregion.compacting.pipeline.segments.limit. The default is currently 4,
you can try it with 2.
bq. To further reduce these compares you can decrease the size of the CSLM by
decreasing hbase.memstore.inmemoryflush.threshold.factor . The current default
is 0.1 but you can try 0.02 it worked well in the past.
Let me try this.
[~anastas]
bq. I saw the flushes not fast enough in all the tests I have done.
As you suggest, NOT flushing fast enough is not a new problem. It has been with
us always. I'm just trying to figure if we are doing better (or worse) with our
new defaults.
bq. Is the Eshcar's fix to HBASE-18294 included?
It is there, yes.
Let me add logging. In old days we'd have a log saying we'd hit the memstore
limit. Now we just throw region busy exception (What [~anoop.hbase] says above
..."The issue Stack mentioned is he is getting so many RegionTooBusyExceptions
at client side. ").
Thanks all. Will be back w/ more info. If anyone manages to run other tests or
compares to branch-1, dump your findings in there. 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: 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)
