Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Thu, 21 Jan 2016 15:11:40 +0000 (UTC)
From: "Eric Newton (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12930171.1452786145000.171461.1453389100008@Atlassian.JIRA>
In-Reply-To: <JIRA.12930171.1452786145000@Atlassian.JIRA>
References: <JIRA.12930171.1452786145000@Atlassian.JIRA>
 <JIRA.12930171.1452786145345@arcas>
Subject: [jira] [Commented] (ACCUMULO-4112) MinC start/stop updates are
 always hsync'd
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Eric Newton commented on ACCUMULO-4112:
---------------------------------------

[~ctubbsii] thought of an interesting issue:

 * tablet finishes a minor compaction
 * the metadata table is updated with a new file
 * the WALog gets the "MinC complete" marker (not hsync'd)
 * the tablet proceeds to major compact away the reference to the recent MinC file
 * tablet server crashes before the WALog is sync'd

In this case, the mutations in the WALog will be replayed, and they exist in the tablet's existing files.

Perhaps it is better to use the Durability of the appropriate meta table, rather than some fixed Durability value.


> MinC start/stop updates are always hsync'd
> ------------------------------------------
>
>                 Key: ACCUMULO-4112
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4112
>             Project: Accumulo
>          Issue Type: Bug
>          Components: tserver
>         Environment: Fluo testing on a 20-node cluster
>            Reporter: Eric Newton
>            Assignee: Eric Newton
>            Priority: Minor
>         Attachments: MinCFlushPerfTest.java, Sync-Flush-Log-Performance.png
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> [~kturner] writes:
> {quote}
> I was running a Fluo test with 1.8.0-SNAP on my workstation.  My Fluo table had a ton of tablets.   I was seeing terrible performance.   I started looking at the tserver and noticed it was always calling hsync.  I tracked down the problem to the fact that when minc start and stop events are written to the log they are always written w/ sync level.   My poor little tserver was constantly minor compacting (probably had around 600 tablets that were all being written to).  
> I changed the test config to create like 15 tablets and the performance was much better.  All cores were 100% utilized, which was not the case when hsync was always called.
> {quote}


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)