[ https://issues.apache.org/jira/browse/HBASE-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13168951#comment-13168951 ]
Hudson commented on HBASE-5017: ------------------------------- Integrated in HBase-0.92 #188 (See [https://builds.apache.org/job/HBase-0.92/188/]) HBASE-5017 Bump the default hfile.block.cache.size because of HFileV2 jdcryans : Files : * /hbase/branches/0.92/CHANGES.txt * /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/HBaseConfiguration.java * /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/HConstants.java * /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/hfile/CacheConfig.java * /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFile.java * /hbase/branches/0.92/src/main/resources/hbase-default.xml > Bump the default hfile.block.cache.size because of HFileV2 > ---------------------------------------------------------- > > Key: HBASE-5017 > URL: https://issues.apache.org/jira/browse/HBASE-5017 > Project: HBase > Issue Type: Improvement > Affects Versions: 0.92.0 > Reporter: Jean-Daniel Cryans > Assignee: Jean-Daniel Cryans > Priority: Blocker > Fix For: 0.92.0, 0.94.0 > > Attachments: HBASE-5017-trunk-v2.patch, HBASE-5017-trunk.patch, > HBASE-5017.patch > > > Here's the email I sent to the mailing list describing the problem: > {quote} > A thought just stuck me while I was writing down a more detailed block > caching documentation: with HFileV2, the indexes now live in the block > cache which means that those who upgrade may all of a sudden get > terrible cache hit ratios because of all that memory taken by the > indexes. This is somewhat mitigated by the fact that people don't > usually need to keep _all_ the index blocks in memory so in the end > we're more efficient. > Which brings me to a question: should we set hfile.block.cache.size > higher since indexes are now kept in the block cache? Currently it's > set to 20%. > Looking over my own production machines I see that the > storefileIndexSize is around 600-700MB so that's potentially how much > more data I'd have to block cache (more likely it's half of that > that's really being used actively). > What would be a good new default? 25%? 30%? How do we handle those > that will be pushed over the BC+memstore size limit because of that > change? > {quote} > I'll bump this to 25% and put in the release note the fact that people should > verify their settings before upgrading to make sure memstore+block cache > isn't over 80% (meaning they'd haven't change the block cache size but would > have bumped the memstores from 40% to 60%). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira