accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Turner (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-4146) Per-durability write-ahead logs
Date Fri, 19 Feb 2016 20:03:18 GMT


Keith Turner commented on ACCUMULO-4146:

In screenshot-1 Continuous ingest (CI) was running on 8 d2.xlarge EC2 tservers.   The CI table
had 2K tablets and was constantly minor compacting.   Each minor compaction wrote an entry
to the metadata table, which caused and hsync on that tserver.   So at least one of the tservers
was constantly calling hsync.  While test was running I reconfigured the accumulo metadata
table to use flush and performance improved.

> Per-durability write-ahead logs
> -------------------------------
>                 Key: ACCUMULO-4146
>                 URL:
>             Project: Accumulo
>          Issue Type: Improvement
>            Reporter: Christopher Tubbs
>             Fix For: 1.8.0
>         Attachments: screenshot-1.png
> [~kturner] showed me a scenario with Continuous Ingest, where the system was configured
to use "flush" for it's durability, but the Metadata table was configured to use "sync" (default
for metadata). When the system grew large enough to have many tablets, lots of tablets were
constantly writing to the metadata table on a relatively few number of tablet servers. This
caused all ingest to drop to 0 very frequently as the tables waiting on a "flush" had to wait
for the WAL to "sync".
> This problem is primarily caused by the fact that we have only one WAL per tablet server,
and so tablet writes waiting on a flush had to wait on a sync if any concurrent write to the
tablet server required a sync.
> We could possibly alleviate this problem if we permitted tablet servers to have multiple
WALs open. One potentially good way to manage these multiple WALs is to group them by durability,
so there'd be one WAL for sync, and another for flush. That way, writes requiring a flush
would not wait on sync's.

This message was sent by Atlassian JIRA

View raw message