Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Mon, 30 Jun 2014 20:20:25 +0000 (UTC)
From: "Keith Turner (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12720451.1402433359185.75626.1404159625290@arcas>
In-Reply-To: <JIRA.12720451.1402433359185@arcas>
References: <JIRA.12720451.1402433359185@arcas>
Subject: [jira] [Commented] (ACCUMULO-2889) Batch metadata table updates for
 new walogs
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Keith Turner commented on ACCUMULO-2889:
----------------------------------------

bq. But since those are separate thrift calls, they'll all be done in their own thread, right?

No, one thread will take all of the tablet updates for a tablet server and repeatedly call that method.  For the gory details, see sendMutationsToTabletServer() in TabletServerBatchWriter (there is a special case for a single mutation, skip past that).

> Batch metadata table updates for new walogs
> -------------------------------------------
>
>                 Key: ACCUMULO-2889
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-2889
>             Project: Accumulo
>          Issue Type: Improvement
>    Affects Versions: 1.5.1, 1.6.0
>            Reporter: Jonathan Park
>            Assignee: Jonathan Park
>         Attachments: ACCUMULO-2889.0.patch.txt, ACCUMULO-2889.1.patch, accumulo-2889-withpatch.png, accumulo-2889_withoutpatch.png, batch_perf_test.sh, run_all.sh, start-ingest.sh
>
>
> Currently, when we update the Metadata table with new loggers, we will update the metadata for each tablet serially. We could optimize this to instead use a batchwriter to send all metadata updates for all tablets in a batch.
> A few special cases include:
> - What if the !METADATA tablet was included in the batch?
> - What about the root tablet?
> Benefit:
> In one of our clusters, we're experiencing particularly slow HDFS operations leading to large oscillations in ingest performance. We haven't isolated the cause in HDFS but when we profile the tservers, we noticed that they were waiting for metadata table operations to complete. This would target the waiting.
> Potential downsides:
> Given the existing locking scheme, it looks like we may have to lock a tablet for slightly longer (we'll lock for the duration of the batch).


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