Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <20345925.115841283352475141.JavaMail.jira@thor>
Date: Wed, 1 Sep 2010 10:47:55 -0400 (EDT)
From: "stack (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Subject: [jira] Commented: (HBASE-2945) stop using string for block name in
 LRU block cache/hfile
In-Reply-To: <27760153.107231283304533668.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

stack commented on HBASE-2945:
------------------------------

bq. The LRU is currently backed by a ConcurrentHashMap and I don't think there's a way to use byte[] on that...

Yes, we'd need to make a class to wrap byte array and used memcmp for comparator.

bq. I think if we are going to do a revamp of the block cache we should come up with a good set of benchmarks to run.

+1

bq. Also, we should review the high/low watermark values. I made those up rather arbitrarily.

And they should evolve with the loading if possible.  If read-only loading, give over more of heap to block cache.  Revive a soft references cache?  I couldn't make it work w/o OOME'ing before but that was a good while back.


> stop using string for block name in LRU block cache/hfile
> ---------------------------------------------------------
>
>                 Key: HBASE-2945
>                 URL: https://issues.apache.org/jira/browse/HBASE-2945
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.89.20100621
>            Reporter: ryan rawson
>
> all my profiling runs indicate there is a large number of string/char[] objects and string manipulation is taking a long time in profiling runs.  These come from the LRU block cache, block id.  Also we should support the eviction of blocks belonging to particular hfiles, and the current code doesn't help with that right now.
> Let's do something better.  Whatever that might be.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.