[
https://issues.apache.org/jira/browse/ACCUMULO-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15108837#comment-15108837
]
Eric Newton commented on ACCUMULO-4112:
---------------------------------------
Discussing this offline with [~kturner], it seems that the current recovery
code should handle failed writes of the "stop MinC" to the WALog. This is very
tricky business, of course. The tablet server updates the metadata table for a
MinC before writing the "stop MinC" marker to the WALog, so we have always
needed to recover from a failure between the two steps. Failure to write the
marker should not add more failures, except if the user is lowering the
Durability of their own mutations. But that trade-off is entirely up to the
user.
> 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
>
>
> [~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)
