[
https://issues.apache.org/jira/browse/HBASE-15240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15145260#comment-15145260
]
stack commented on HBASE-15240:
-------------------------------
Doing quick profile on prefetch -- it takes a long time to load the block cache
-- I see the attached when we are prefetching one big file. We are mostly in
readBlockDataInternal, which is no surprise. Then there is the usual suspects,
compares. For context, perf top shows readBlockDataInternal doing < 1% of total
CPU so pepper the JMC 25% with that knowledge. Looking at inlining, I see:
org.apache.hadoop.hbase.io.hfile.HFileBlock$FSReaderImpl::readBlockData (354
bytes) too big
readBlockDataInternal is likely the same but inlining reports it being
zombified.. so maybe we should make it final but if I were to guess, inlining
would again report it too big.
I thought I was seeing parse of path Strings but must have been imagining it...
Need to make prefetch go faster.
(Matteo and I were looking at something else last night slightly related....
readBlock in blockSeek from HFileReaderImpl... it was taking 10%+ of CPU when
YCSB doing mostly writes. It was reported as too big to inline too. Need to
fix. And then there are all the compares both here and what we were looking at
last night. We need to work on those -- avoid some (e.g. Matteo asked why we
are doing family parse and compares when below a Store at all?) -- and
study/profile/fix up the reset. Just saying.)
> Go Big BucketCache Fixes
> ------------------------
>
> Key: HBASE-15240
> URL: https://issues.apache.org/jira/browse/HBASE-15240
> Project: HBase
> Issue Type: Umbrella
> Components: BucketCache
> Reporter: stack
> Assignee: stack
> Attachments: Screen Shot 2016-02-10 at 6.27.26 AM.png
>
>
> Umbrella issue to which we will attach issues that prevent bucketcache going
> big; there's a few.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
