cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3578) Multithreaded commitlog
Date Sun, 27 Oct 2013 23:49:30 GMT


Jonathan Ellis commented on CASSANDRA-3578:

bq. are we talking about synchronization in the allocation, so only 1 thread writes the size
and end 

Right.  Otherwise we can have a mutation that has been fsynced, that we can't actually replay
because an earlier mutation didn't finish before the fsync.

OTOH I think this is a non-problem for Batch mode, and maybe we can wave it away for Periodic
as "you should use Batch if you care."

bq. Other option is replace recycle with discard

That's basically what mfiguiere was saying about zeroing out recycled segments.  (Probably
still more efficient than creating new ones.)

> 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