Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Sun, 1 Dec 2013 02:13:35 +0000 (UTC)
From: "Jonathan Ellis (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12533985.1323146554572.50218.1385864015722@arcas>
In-Reply-To: <JIRA.12533985.1323146554572@arcas>
References: <JIRA.12533985.1323146554572@arcas>
Subject: [jira] [Comment Edited] (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=13835923#comment-13835923 ] 

Jonathan Ellis edited comment on CASSANDRA-3578 at 12/1/13 2:12 AM:
--------------------------------------------------------------------

bq. We point next to next, which is absolutely correct

I understand what sync is doing; my point is that xxxxSyncMarkerPosition always points to the *last* offset before which the contents are synced, which we'll revisit when we sync again / write the next marker (referred to appropriately as {{nextMarker}} in the code).  Your own comments refer to "last" or "previous" in multiple places which speaks to how difficult it is to avoid thinking of it that way. :)

(N.B. This is also clear in the usage of isFullySynced -- intuitively, we want to know if "the *last* place we synced was the end of the buffer" which is unclear if the variable is named *next*.)


was (Author: jbellis):
bq. We point next to next, which is absolutely correct

I understand what sync is doing; my point is that xxxxSyncMarkerPosition always points to the *last* offset before which the contents are synced, which we'll revisit when we sync again / write the next marker (referred to appropriately as {{nextMarker}} in the code).  Your own comments refer to "last" or "previous" in multiple places which speaks to how difficult it is to avoid thinking of it that way. :)

(N.B. This is also clear in the usage of isFullySynced -- intuitively, we want to know if "the *last8 place we synced was the end of the buffer" which is unclear if the variable is named *next*.)

> Multithreaded commitlog
> -----------------------
>
>                 Key: CASSANDRA-3578
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3578
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Jonathan Ellis
>            Assignee: Benedict
>            Priority: Minor
>              Labels: performance
>         Attachments: 0001-CASSANDRA-3578.patch, ComitlogStress.java, Current-CL.png, Multi-Threded-CL.png, TestEA.java, latency.svg, oprate.svg, 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)