Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 7 Nov 2013 19:49:17 +0000 (UTC)
From: "Vijay (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12533985.1323146554572.36877.1383853757779@arcas>
In-Reply-To: <JIRA.12533985.1323146554572@arcas>
References: <JIRA.12533985.1323146554572@arcas>
Subject: [jira] [Commented] (CASSANDRA-3578) Multithreaded commitlog
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Vijay commented on CASSANDRA-3578:
----------------------------------

{quote}
we could have A allocate, B begin sync, C allocate, C write, B see counters equal
{quote}
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).

{quote}
we didn't know there were unfinished writes behind us
{quote}
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: https://issues.apache.org/jira/browse/CASSANDRA-3578
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Jonathan Ellis
>            Assignee: Vijay
>            Priority: Minor
>              Labels: performance
>         Attachments: 0001-CASSANDRA-3578.patch, ComitlogStress.java, 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
(v6.1#6144)