Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8F23C18938 for ; Fri, 12 Feb 2016 20:41:18 +0000 (UTC) Received: (qmail 47012 invoked by uid 500); 12 Feb 2016 20:41:18 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 46962 invoked by uid 500); 12 Feb 2016 20:41:18 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 46914 invoked by uid 99); 12 Feb 2016 20:41:18 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Feb 2016 20:41:18 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 2DBC02C1F64 for ; Fri, 12 Feb 2016 20:41:18 +0000 (UTC) Date: Fri, 12 Feb 2016 20:41:18 +0000 (UTC) From: "stack (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-15240) Go Big BucketCache Fixes MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ 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)