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