[
https://issues.apache.org/jira/browse/HBASE-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12905084#action_12905084
]
Jonathan Gray commented on HBASE-2945:
--------------------------------------
bq. And they should evolve with the loading if possible. If read-only loading,
give over more of heap to block cache.
More heap to block cache would be a different config parameter than the
watermarks, but completely agree as well. I think once we make the jump to a
more complex picture of "load", we can think about using that information for
heap allocation within the RS.
For the watermarks, we are currently triggering an eviction at like 85% full
and draining to 75% (of the block caches total heap). So if we give default of
20% to block cache, in practice we'll usually only fill to 85% of that 20%
(~17%). The MemStore has a high watermark of 40% of total heap and low of 35%.
bq. Revive a soft references cache?
That's a big -1 from me. This would take us back to before HeapSize days and
watermarks above would go away (we lose the ability to control this stuff).
And all testing we did way back showed lots of undesirable behavior from soft
refs.
> 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.
