[ https://issues.apache.org/jira/browse/HBASE-15640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15238265#comment-15238265 ]
Hadoop QA commented on HBASE-15640: ----------------------------------- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 4s {color} | {color:red} HBASE-15640 does not apply to master. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/0.2.1/precommit-patchnames for help. {color} | \\ \\ || Subsystem || Report/Notes || | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12798405/bc.ui.patch | | JIRA Issue | HBASE-15640 | | Console output | https://builds.apache.org/job/PreCommit-HBASE-Build/1376/console | | Powered by | Apache Yetus 0.2.1 http://yetus.apache.org | This message was automatically generated. > L1 cache doesn't give fair warning that it is showing partial stats only when > it hits limit > ------------------------------------------------------------------------------------------- > > Key: HBASE-15640 > URL: https://issues.apache.org/jira/browse/HBASE-15640 > Project: HBase > Issue Type: Sub-task > Components: BlockCache > Reporter: stack > Assignee: stack > Attachments: Screen Shot 2016-04-12 at 4.21.50 PM.png, bc.ui.patch > > > I was baffled looking at L1 Cache because it was stuck at 100k blocks and > only 'loading' 3G of data according to the UI. When I looked in log, all the > numbers looked write in the Cache summary reported in log. > Turns out our buckecache UI template will cut off calculating stats at a > limit --which is probably what we want -- but the fact that it has done this > should be more plain. -- This message was sent by Atlassian JIRA (v6.3.4#6332)