cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vijay (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3578) Multithreaded commitlog
Date Thu, 07 Nov 2013 03:43:20 GMT


Vijay commented on CASSANDRA-3578:

Hi Benedict, archiver.maybeArchive(segment.getPath(), segment.getName()) is a blocking call
and will need to be a separate thread it might involve user defined archival.

sync() would mark things as flushed to disk that weren't, which would result in log messages
never being persisted
My understand is that.... Calling force will sync the dirty pages and if we do a concurrent
writes to the same page they will be marked as dirty and will be synched in the next call,
how will we loose the log messages?

I still like the original approach :) of creating files (it may be just me) because of simplicity
and we can be aggressive in allocator threads similar to your patch (to create empty files
and deleting them).

> Multithreaded commitlog
> -----------------------
>                 Key: CASSANDRA-3578
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Jonathan Ellis
>            Assignee: Vijay
>            Priority: Minor
>              Labels: performance
>         Attachments: 0001-CASSANDRA-3578.patch,, Current-CL.png,
Multi-Threded-CL.png, parallel_commit_log_2.patch
> Brian Aker pointed out a while ago that allowing multiple threads to modify the commitlog
simultaneously (reserving space for each with a CAS first, the way we do in the SlabAllocator.Region.allocate)
can improve performance, since you're not bottlenecking on a single thread to do all the copying
and CRC computation.
> Now that we use mmap'd CommitLog segments (CASSANDRA-3411) this becomes doable.
> (moved from CASSANDRA-622, which was getting a bit muddled.)

This message was sent by Atlassian JIRA

View raw message