[
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.
