Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E1F49DE43 for ; Thu, 5 Jul 2012 18:16:35 +0000 (UTC) Received: (qmail 73983 invoked by uid 500); 5 Jul 2012 18:16:35 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 73887 invoked by uid 500); 5 Jul 2012 18:16:35 -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 73683 invoked by uid 99); 5 Jul 2012 18:16:35 -0000 Received: from issues-vm.apache.org (HELO issues-vm) (140.211.11.160) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Jul 2012 18:16:35 +0000 Received: from isssues-vm.apache.org (localhost [127.0.0.1]) by issues-vm (Postfix) with ESMTP id 29811142863 for ; Thu, 5 Jul 2012 18:16:35 +0000 (UTC) Date: Thu, 5 Jul 2012 18:16:35 +0000 (UTC) From: "Jean-Daniel Cryans (JIRA)" To: issues@hbase.apache.org Message-ID: <1002136676.10097.1341512195171.JavaMail.jiratomcat@issues-vm> In-Reply-To: <652064642.383.1341295742165.JavaMail.jiratomcat@issues-vm> Subject: [jira] [Commented] (HBASE-6312) Make BlockCache eviction thresholds configurable MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13407348#comment-13407348 ] Jean-Daniel Cryans commented on HBASE-6312: ------------------------------------------- bq. According to your suggestion, shall we need to make that gap (between the minimum and acceptable factor) configurable at least? We can, I just don't know how useful that's gonna be. It can hardly be worse than it is right now tho :) bq. Maybe We should evict only after cache size is large than hfile.block.cache.size, and allow ~15% burstiness before blocking. It seems to me that we'd just have the reverse problem. The real problem here is that LruBlockCache won't let us use exactly the amount of memory we want, it's like driving a car and the best you can do is steering all the way left or all the way right because keeping it centered would require too much effort. Right now I'd be in favor of setting the acceptable factor to 99% and the minimum at 95% since it's really hard to overflow and there's no blocking. We can make the minimum configurable so that if someone sees that it's evicting too often they can tune it down. > Make BlockCache eviction thresholds configurable > ------------------------------------------------ > > Key: HBASE-6312 > URL: https://issues.apache.org/jira/browse/HBASE-6312 > Project: HBase > Issue Type: Improvement > Components: io > Affects Versions: 0.94.0 > Reporter: Jie Huang > Priority: Minor > Attachments: hbase-6312.patch > > > Some of our customers found that tuning the BlockCache eviction thresholds made test results different in their test environment. However, those thresholds are not configurable in the current implementation. The only way to change those values is to re-compile the HBase source code. We wonder if it is possible to make them configurable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira