You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Oleg Anastasyev (JIRA)" <ji...@apache.org> on 2013/09/24 19:30:03 UTC

[jira] [Comment Edited] (CASSANDRA-6079) Memtables flush is delayed when having a lot of batchlog activity, making node OOM

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

Oleg Anastasyev edited comment on CASSANDRA-6079 at 9/24/13 5:28 PM:
---------------------------------------------------------------------

Do you mean the replica, which is target for one of batched mutations ? I see a hint is written by BM if it cannot deliver one of mutations serialized to batchlog record (in replaySerializedMutation and attemptDirectDelivery) , so as i understood HintManager bothers further about delivering it to failed replica when it is back online. So as soon as BM writes a hint(s) for (all of) failed replica(s), BM has nothing to do with batchlog record, so no all partitions scanning neccessary.

Am I missing something again ?
                
      was (Author: m0nstermind):
    Do you mean the replica, which is target for one of batched mutations ? I see a hint is written by BM if it cannot deliver one of mutations serialized to backlog record (in replaySerializedMutation and attemptDirectDelivery) , so as i understood HintManager bothers further about delivering it to failed replica when it is back online. So as soon as BM writes a hint(s) for (all of) failed replica(s), BM has nothing to do with batchlog record, so no all partitions scanning neccessary.

Am I missing something again ?
                  
> 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