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