Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 15 Jul 2014 23:01:08 +0000 (UTC)
From: "Vladimir Rodionov (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12623489.1355291472777.49616.1405465268549@arcas>
In-Reply-To: <JIRA.12623489.1355291472777@arcas>
References: <JIRA.12623489.1355291472777@arcas>
Subject: [jira] [Commented] (HBASE-7336) HFileBlock.readAtOffset does not
 work well with multiple threads
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-7336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14062814#comment-14062814 ] 

Vladimir Rodionov commented on HBASE-7336:
------------------------------------------

I monitor thread stack traces during test run. Usually, just one thread (Scanner) is running, all others are waiting on DFSInputStream in some places (as I said, too many synchronized methods). This is HDFS, not HBase.

> HFileBlock.readAtOffset does not work well with multiple threads
> ----------------------------------------------------------------
>
>                 Key: HBASE-7336
>                 URL: https://issues.apache.org/jira/browse/HBASE-7336
>             Project: HBase
>          Issue Type: Sub-task
>          Components: Performance
>            Reporter: Lars Hofhansl
>            Assignee: Lars Hofhansl
>            Priority: Critical
>             Fix For: 0.94.4, 0.95.0
>
>         Attachments: 7336-0.94.txt, 7336-0.96.txt
>
>
> HBase grinds to a halt when many threads scan along the same set of blocks and neither read short circuit is nor block caching is enabled for the dfs client ... disabling the block cache makes sense on very large scans.
> It turns out that synchronizing in istream in HFileBlock.readAtOffset is the culprit.


--
This message was sent by Atlassian JIRA
(v6.2#6252)