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 33DB3980B for ; Sat, 4 Aug 2012 00:47:04 +0000 (UTC) Received: (qmail 48733 invoked by uid 500); 4 Aug 2012 00:47:03 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 48692 invoked by uid 500); 4 Aug 2012 00:47:03 -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 48678 invoked by uid 99); 4 Aug 2012 00:47:03 -0000 Received: from issues-vm.apache.org (HELO issues-vm) (140.211.11.160) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 04 Aug 2012 00:47:03 +0000 Received: from isssues-vm.apache.org (localhost [127.0.0.1]) by issues-vm (Postfix) with ESMTP id 5213A142851 for ; Sat, 4 Aug 2012 00:47:03 +0000 (UTC) Date: Sat, 4 Aug 2012 00:47:03 +0000 (UTC) From: "Todd Lipcon (JIRA)" To: issues@hbase.apache.org Message-ID: <1420316249.12761.1344041223338.JavaMail.jiratomcat@issues-vm> In-Reply-To: <1288403546.25460.1341870635355.JavaMail.jiratomcat@issues-vm> Subject: [jira] [Commented] (HBASE-6358) Bulkloading from remote filesystem is problematic 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-6358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13428508#comment-13428508 ] Todd Lipcon commented on HBASE-6358: ------------------------------------ bq. not breaking the current use case of non-local bulk loading when size or speed requirements are modest If the size and speed don't matter, then wouldn't you have just used a normal (non-bulk-load) MR job to load the data? I think funneling the load through one host basically defeats the purpose of bulk load. Perhaps it could be available as an option for people just testing out, but I would prefer the default to be a failure, and you have to enable the copy with a {{-copyToCluster}} or something. > Bulkloading from remote filesystem is problematic > ------------------------------------------------- > > Key: HBASE-6358 > URL: https://issues.apache.org/jira/browse/HBASE-6358 > Project: HBase > Issue Type: Bug > Components: regionserver > Affects Versions: 0.94.0 > Reporter: Dave Revell > Assignee: Dave Revell > Attachments: 6358-suggestion.txt, HBASE-6358-trunk-v1.diff, HBASE-6358-trunk-v2.diff, HBASE-6358-trunk-v3.diff > > > Bulk loading hfiles that don't live on the same filesystem as HBase can cause problems for subtle reasons. > In Store.bulkLoadHFile(), the regionserver will copy the source hfile to its own filesystem if it's not already there. Since this can take a long time for large hfiles, it's likely that the client will timeout and retry. When the client retries repeatedly, there may be several bulkload operations in flight for the same hfile, causing lots of unnecessary IO and tying up handler threads. This can seriously impact performance. In my case, the cluster became unusable and the regionservers had to be kill -9'ed. > Possible solutions: > # Require that hfiles already be on the same filesystem as HBase in order for bulkloading to succeed. The copy could be handled by LoadIncrementalHFiles before the regionserver is called. > # Others? I'm not familiar with Hadoop IPC so there may be tricks to extend the timeout or something else. > I'm willing to write a patch but I'd appreciate recommendations on how to proceed. -- 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