Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 24 Sep 2013 17:06:21 +0000 (UTC)
From: "Oleg Anastasyev (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12670028.1379935215924.10451.1380042381786@arcas>
In-Reply-To: <JIRA.12670028.1379935215924@arcas>
References: <JIRA.12670028.1379935215924@arcas>
Subject: [jira] [Issue Comment Deleted] (CASSANDRA-6079) Memtables flush is
 delayed when having a lot of batchlog activity, making node OOM
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Anastasyev updated CASSANDRA-6079:
---------------------------------------

    Comment: was deleted

(was: Batchlog functionality is critical for our current application (having batch mutation consistency within 60sec, like it is in current implementation is not acceptable for us), so we considering replayAllBatches to run every rpcwrite timeout interval, which could be costly with current batchlog implementation.

So, I looked further at Batchlog manager and see a room for improvement there:
Currently it rescans the whole dataset to find batches to replay. A slight change in data model can eliminate this. a quick guess is to have batchlog table as
(
minuteoftheday int,
written_at timestamp,
id uuid,
data blob
primary key (minuteoftheday, written_at)
)

so batches are split to buckets and stored in order of their arrival to local node.
BatchlogManager on each replay cycle selects batchlog records with written_at between (currentTime-RpcWriteTimeout*2) and (currentTime-RpcWriteTimeout). Only on the very 1st cycle after startup it scans all records to find batchlog records from previous node run.

This way, at any replay cycle, except the very first, BM scans only batchlog entries for last couple of seconds. And its performance does not depend on batchlog CF compaction. And because it scans over recent columns only it will unlikely to hit to disk.

Am I missing something ?
(we could implement this rewrite, if you find it useful for others as well)

)
    
> Memtables flush is delayed when having a lot of batchlog activity, making node OOM
> ----------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-6079
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6079
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Oleg Anastasyev
>            Assignee: Oleg Anastasyev
>            Priority: Minor
>             Fix For: 1.2.11, 2.0.2
>
>         Attachments: NoWaitBatchlogCompaction.diff
>
>
> Both MeteredFlusher and BatchlogManager share the same OptionalTasks thread. So, when batchlog manager processes its tasks no flushes can occur. Even more, batchlog manager waits for batchlog CF compaction to finish.
> On a lot of batchlog activity this prevents memtables from flush for a long time, making the node OOM.
> Fixed this by moving batchlog to its own thread and not waiting for batchlog compaction to finish.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira