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 6EC9B200CC8 for ; Thu, 29 Jun 2017 17:13:07 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 6D3F3160BDF; Thu, 29 Jun 2017 15:13:07 +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 BBB71160BED for ; Thu, 29 Jun 2017 17:13:06 +0200 (CEST) Received: (qmail 53192 invoked by uid 500); 29 Jun 2017 15:13:04 -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 53181 invoked by uid 99); 29 Jun 2017 15:13:04 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Jun 2017 15:13:04 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 3EDE7C00A6 for ; Thu, 29 Jun 2017 15:13:04 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id M_jHw1vrEFMb for ; Thu, 29 Jun 2017 15:13:03 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 60A4D5FE2F for ; Thu, 29 Jun 2017 15:13:02 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 3DDF7E0DD4 for ; Thu, 29 Jun 2017 15:13:01 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 5C632245BD for ; Thu, 29 Jun 2017 15:13:00 +0000 (UTC) Date: Thu, 29 Jun 2017 15:13:00 +0000 (UTC) From: "ramkrishna.s.vasudevan (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-18294) Flush is based on data size instead of heap size MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Thu, 29 Jun 2017 15:13:07 -0000 [ https://issues.apache.org/jira/browse/HBASE-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068455#comment-16068455 ] ramkrishna.s.vasudevan commented on HBASE-18294: ------------------------------------------------ In RegionServerAccounting we are trying to do all the flush calculation. Check 'isAboveHighWaterMark()'. There we still consider the heapSize for the global heap pressure related flushes. What is that you are observing now? Are you seeing some different behaviour now? Offheap memstores need this change so that we are able to decide the region flush based on data size alone as the whole data is offheap. > Flush is based on data size instead of heap size > ------------------------------------------------ > > Key: HBASE-18294 > URL: https://issues.apache.org/jira/browse/HBASE-18294 > Project: HBase > Issue Type: Bug > Reporter: Eshcar Hillel > Assignee: Eshcar Hillel > > A region is flushed if its memory component exceed a threshold (default size is 128MB). > A flush policy decides whether to flush a store by comparing the size of the store to another threshold (that can be configured with hbase.hregion.percolumnfamilyflush.size.lower.bound). > Currently the implementation (in both cases) compares the data size (key-value only) to the threshold where it should compare the heap size (which includes index size, and metadata). -- This message was sent by Atlassian JIRA (v6.4.14#64029)