Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 7 Nov 2013 17:11:30 +0000 (UTC)
From: "Benedict (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12533985.1323146554572.35652.1383844290251@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=13816131#comment-13816131 ] 

Benedict commented on CASSANDRA-3578:
-------------------------------------

Well, one possibility is allocating a new ReadWriteLock object (well, a wrapper with an extra state flag) after each sync, which we readLock() before we allocate a section, and writeLock() when we come to sync, after which we invalidate the object and start again. There is some extra synchronization (two extra CASes, though might be able to eliminate one of the existing ones), but that's unlikely to hurt too much, and it is pretty simple.

Obviously, we need to make sure that no new writes block on the attempt to lock this object, so before we go to writeLock on sync() we should probably swap in a new lock object, so that new writes go there instead. We'll consider the log complete up to the last position allocated prior to our swapping the lock object. This might permit some writes to be ahead of where the CL thinks we've gotten to, which won't be replayable, but that's fine - those are in "the future" anyway, so we're okay to drop them until next sync.

> 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)