You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Appy (JIRA)" <ji...@apache.org> on 2018/03/15 06:25:00 UTC
[jira] [Comment Edited] (HBASE-20188) [TESTING] Performance

    [ https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16399970#comment-16399970 ] 

Appy edited comment on HBASE-20188 at 3/15/18 6:24 AM:
-------------------------------------------------------

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.
Can do complete one as mentioned previously when things look good.


was (Author: appy):
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
(v7.6.3#76005)