hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-953) Reevaluate HBASE-288 block caching work; should it be enabled always?
Date Sat, 25 Oct 2008 02:19:46 GMT

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

stack commented on HBASE-953:
-----------------------------

Using SoftSorteMap instead of commons ReferenceMap seems to do better.  Still not good enough
though; I get "OOME: GC Time and OutOfMemoryError" which doesn't exactly kill it.. it hobbles
along.  I see random reading we're getting 90% cache hits if run after a sequential read which
means cache has been warmed but the random reads should be going faster than they are.  They're
slowed by all the GCing I'm seeing (I have gc logging enabled).  Trying w/ 1.6.0_10 JVM. 
Was using 1.7.  If random reads were just as fast as without block reads, it would be worth
enabling by default because of the faster sequential reads, scans and compactions.

> Reevaluate HBASE-288 block caching work; should it be enabled always?
> ---------------------------------------------------------------------
>
>                 Key: HBASE-953
>                 URL: https://issues.apache.org/jira/browse/HBASE-953
>             Project: Hadoop HBase
>          Issue Type: Task
>            Reporter: stack
>            Priority: Critical
>             Fix For: 0.19.0
>
>
> Go back and take another look at the Tom White work.  We've gotten boost in writing and
scanning because of J-D work.  HBASE-288 looks like it boosts sequential reads and perhaps
random read a little.  Take another look.

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


Mime
View raw message