hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ramkrishna.s.vasudevan (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-14613) Remove MemStoreChunkPool?
Date Wed, 23 Mar 2016 12:17:25 GMT

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

ramkrishna.s.vasudevan edited comment on HBASE-14613 at 3/23/16 12:17 PM:
--------------------------------------------------------------------------

I conducted a simple set of tests with G1GC. Max heap size is 40G and 50 regions
single node tests - with YCSB client and 55 threads. Also I did some tweaks such that the
flush from memstore will not write to a file and just discard the memstore snapshot. SKIP_WAL
is also enabled. 
Thro put ops/sec
||MSLAB without chunkpool||with mslab and with Chunkpool||without mslab and without chunkpool||
|1920.0463846930513|1471.2768168302587|2196.79151655224|

In my YCSB set up I have 1000 columns each of 100 byte length (100KB cells).

Coming to the GC pauses in sec
 ||MSLAB without chunkpool||with mslab and with Chunkpool||without mslab and without chunkpool||
|72.11s|85.91s|87.44s|

I think Elliot's point is valid here. We get better through put with G1GC in trunk without
MSLAB and without chunk pool.
 In our case where we are trying to use Offheap memstore and doing a chunk pool of that offheap
memstore is definitely performing better than the trunk version of using MSLAB and with chunkpool
(with G1GC enabled).
The through put is slightly  better 2261.0680948982304 ops/sec than the trunk (no MSLAB and
no chunk pool case).


was (Author: ram_krish):
I conducted a simple set of tests with G1GC
single node tests - with YCSB client and 55 threads. Also I did some tweaks such that the
flush from memstore will not write to a file and just discard the memstore snapshot. SKIP_WAL
is also enabled. 
Thro put ops/sec
||MSLAB without chunkpool||with mslab and with Chunkpool||without mslab and without chunkpool||
|1920.0463846930513|1471.2768168302587|2196.79151655224|

In my YCSB set up I have 1000 columns each of 100 byte length (100KB cells).

Coming to the GC pauses in sec
 ||MSLAB without chunkpool||with mslab and with Chunkpool||without mslab and without chunkpool||
|72.11s|85.91s|87.44s|

I think Elliot's point is valid here. We get better through put with G1GC in trunk without
MSLAB and without chunk pool.
 In our case where we are trying to use Offheap memstore and doing a chunk pool of that offheap
memstore is definitely performing better than the trunk version of using MSLAB and with chunkpool
(with G1GC enabled).
The through put is slightly  better 2261.0680948982304 ops/sec than the trunk (no MSLAB and
no chunk pool case).

> Remove MemStoreChunkPool?
> -------------------------
>
>                 Key: HBASE-14613
>                 URL: https://issues.apache.org/jira/browse/HBASE-14613
>             Project: HBase
>          Issue Type: Brainstorming
>            Reporter: Lars Hofhansl
>            Priority: Minor
>         Attachments: 14613-0.98.txt, gc.png, writes.png
>
>
> I just stumbled across MemStoreChunkPool. The idea behind is to reuse chunks of allocations
rather than letting the GC handle this.
> Now, it's off by default, and it seems to me to be of dubious value. I'd recommend just
removing it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message