Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 3A9E9200BD3 for ; Tue, 6 Dec 2016 17:27:06 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 39316160B1B; Tue, 6 Dec 2016 16:27:06 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id E534C160B17 for ; Tue, 6 Dec 2016 17:27:04 +0100 (CET) Received: (qmail 41828 invoked by uid 500); 6 Dec 2016 16:26:59 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 41466 invoked by uid 99); 6 Dec 2016 16:26:59 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Dec 2016 16:26:59 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id DC8AE2C03E3 for ; Tue, 6 Dec 2016 16:26:58 +0000 (UTC) Date: Tue, 6 Dec 2016 16:26:58 +0000 (UTC) From: "Anoop Sam John (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-16417) In-Memory MemStore Policy for Flattening and Compactions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Tue, 06 Dec 2016 16:27:06 -0000 [ https://issues.apache.org/jira/browse/HBASE-16417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15725961#comment-15725961 ] Anoop Sam John commented on HBASE-16417: ---------------------------------------- Why I mentioned abt correcting the GC config and HBase config is that ur tests on data compaction was not using MSLAB where as others. (The initial compares).. So the GC is paying the cost and it might be giving a false indication that data compaction is better. Ya data compaction might be better depending on the key generation. More and more duplicated keys (rk+cf+q+ts+type) means in memory compaction can get rid of many (def table versions = 1).. But I dont think by def we should enable this. Yes we need to consider that more users will go to G1GC. So as per ur tests u say disable memstore chunk pool by default but enable MSLAB is ok? This was/is on by def from long time. I strongly feel we should revisit our BC and memstore % def values. Specially to conisder that we will ON L2 off heap now. The data blocks will go to L2. L1 might have only index blocks.. So we dont need much size there. Even pls note that off heap backed MSLAB pool is all ready in trunk.. We will do tests similar to urs by working with off heap. > In-Memory MemStore Policy for Flattening and Compactions > -------------------------------------------------------- > > Key: HBASE-16417 > URL: https://issues.apache.org/jira/browse/HBASE-16417 > Project: HBase > Issue Type: Sub-task > Reporter: Anastasia Braginsky > Assignee: Eshcar Hillel > Fix For: 2.0.0 > > Attachments: HBASE-16417-benchmarkresults-20161101.pdf, HBASE-16417-benchmarkresults-20161110.pdf, HBASE-16417-benchmarkresults-20161123.pdf, HBASE-16417-benchmarkresults-20161205.pdf > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)