Appy commented on HBASE-20188:
bq. You going to have pretty graphs of GC usage, i/os, CPU too?
Can't this time. We don't have any easy way to collect those in our open source
version (or maybe there's one am not aware of?). And I can't use CM due to
technical (and license too?) reasons - hbase2.0 + hadoop2.7.
bq. At the moment I am getting abysmal perf because we are blocking writes
because we are unable to flush in time.
In that case, i'll not waste time in doing full perf testing. I'll reduce the
scope by reducing number of rows and limiting to single workload.
> [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
> 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