[
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
