[
https://issues.apache.org/jira/browse/HBASE-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13770316#comment-13770316
]
Todd Lipcon commented on HBASE-9553:
------------------------------------
Interested to see the results here. When I tested block cache churn before, I
didn't see heap fragmentation really crop up:
http://blog.cloudera.com/blog/2011/02/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-2/
For testing this improvement, it would be good to produce similar graphs of the
CMS maximum chunk size metric from -XX:+PrintFLSStatistics output under some
workload, and show that the improvement results in less fragmentation over time
for at least some workload(s).
> Pad HFile blocks to a fixed size before placing them into the blockcache
> ------------------------------------------------------------------------
>
> Key: HBASE-9553
> URL: https://issues.apache.org/jira/browse/HBASE-9553
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
>
> In order to make it easy on the garbage collector and to avoid full
> compaction phases we should make sure that all (or at least a large
> percentage) of the HFile blocks as cached in the block cache are exactly the
> same size.
> Currently an HFile block is typically slightly larger than the declared block
> size, as the block will accommodate that last KV on the block. The padding
> would be a ColumnFamily option. In many cases 100 bytes would probably be a
> good value to make all blocks exactly the same size (but of course it depends
> on the max size of the KVs).
> This does not have to be perfect. The more blocks evicted and replaced in the
> block cache are of the exact same size the easier it should be on the GC.
> Thoughts?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
