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 19:49:17 GMT


Vijay commented on CASSANDRA-3578:

we could have A allocate, B begin sync, C allocate, C write, B see counters equal
I am talking about count all the allocation and written, within a segment.... Which is (A
+ B + C)  != (A + B) (which means C or someone else is still writing).

we didn't know there were unfinished writes behind us
Thats fine we will skip those, thats what the current implementation does too, if you are
writing in a sequence and the server stops... the commits which where in the queue are not
written.... We are just moving that queue to the buffer. 
Practically this is less of an concern because there is few nano's out of sync.

Anyways i should stop selling.... :)

> 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