Cassandra
  1. Cassandra
  2. CASSANDRA-6079

Memtables flush is delayed when having a lot of batchlog activity, making node OOM

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Fix Version/s: 1.2.11, 2.0.2
    • Component/s: None
    • Labels:
      None

      Description

      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.

        Activity

        Oleg Anastasyev made changes -
        Comment [ 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)

        ]
        Jonathan Ellis made changes -
        Fix Version/s 1.2.11 [ 12325022 ]
        Priority Major [ 3 ] Minor [ 4 ]
        Jonathan Ellis made changes -
        Status Patch Available [ 10002 ] Resolved [ 5 ]
        Assignee Oleg Anastasyev [ m0nstermind ]
        Reviewer jbellis
        Fix Version/s 2.0.2 [ 12325023 ]
        Resolution Fixed [ 1 ]
        Oleg Anastasyev made changes -
        Status Open [ 1 ] Patch Available [ 10002 ]
        Oleg Anastasyev made changes -
        Field Original Value New Value
        Attachment NoWaitBatchlogCompaction.diff [ 12604564 ]
        Oleg Anastasyev created issue -

          People

          • Assignee:
            Oleg Anastasyev
            Reporter:
            Oleg Anastasyev
            Reviewer:
            Jonathan Ellis
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development