You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Jason Rutherglen (JIRA)" <ji...@apache.org> on 2011/06/10 02:53:58 UTC

[jira] [Commented] (HBASE-3976) Disable Block Cache On Compactions

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

Jason Rutherglen commented on HBASE-3976:
-----------------------------------------

This makes sense!  I think for local data blocks this can further be solved by preventing the read side of the compacted blocks from entering the system IO cache, ala LUCENE-2500.

> Disable Block Cache On Compactions
> ----------------------------------
>
>                 Key: HBASE-3976
>                 URL: https://issues.apache.org/jira/browse/HBASE-3976
>             Project: HBase
>          Issue Type: Improvement
>          Components: regionserver
>    Affects Versions: 0.90.3
>            Reporter: Karthick Sankarachary
>            Assignee: Karthick Sankarachary
>            Priority: Minor
>             Fix For: 0.90.4
>
>         Attachments: HBASE-3976.patch
>
>
> Is there a good reason to believe that caching blocks during compactions is beneficial? Currently, if block cache is enabled on a certain family, then every time it's compacted, we load all of its blocks into the (LRU) cache, at the expense of the legitimately hot ones.
> As a matter of fact, this concern was raised earlier in HBASE-1597, which rightly points out that, "we should not bog down the LRU with unneccessary blocks" during compaction. Even though that issue has been marked as "fixed", it looks like it ought to be reopened.
> Should we err on the side of caution and not cache blocks during compactions period (as illustrated in the attached patch)? Or, can we be selectively aggressive about what blocks do get cached during compaction (e.g., only cache those blocks from the recent files)?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira