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 6B939114BA for ; Mon, 19 May 2014 22:39:39 +0000 (UTC) Received: (qmail 27137 invoked by uid 500); 19 May 2014 22:39:39 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 27097 invoked by uid 500); 19 May 2014 22:39:39 -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 27082 invoked by uid 99); 19 May 2014 22:39:39 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 May 2014 22:39:39 +0000 Date: Mon, 19 May 2014 22:39:39 +0000 (UTC) From: "Andrew Purtell (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (HBASE-9857) Blockcache prefetch option 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-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-9857: ---------------------------------- Summary: Blockcache prefetch option (was: Blockcache prefetch for HFile V3) > Blockcache prefetch option > -------------------------- > > Key: HBASE-9857 > URL: https://issues.apache.org/jira/browse/HBASE-9857 > Project: HBase > Issue Type: Improvement > Reporter: Andrew Purtell > Priority: Minor > Attachments: 9857.patch, 9857.patch > > > Attached patch implements a prefetching function for HFile (v3) blocks, if indicated by a column family or regionserver property. The purpose of this change is to as rapidly after region open as reasonable warm the blockcache with all the data and index blocks of (presumably also in-memory) table data, without counting those block loads as cache misses. Great for fast reads and keeping the cache hit ratio high. Can tune the IO impact versus time until all data blocks are in cache. Works a bit like CompactSplitThread. Makes some effort not to stampede. > I have been using this for setting up various experiments and thought I'd polish it up a bit and throw it out there. If the data to be preloaded will not fit in blockcache, or if as a percentage of blockcache it is large, this is not a good idea, will just blow out the cache and trigger a lot of useless GC activity. Might be useful as an expert tuning option though. Or not. -- This message was sent by Atlassian JIRA (v6.2#6252)