[
https://issues.apache.org/jira/browse/CASSANDRA-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806491#comment-13806491
]
Jonathan Ellis commented on CASSANDRA-3578:
-------------------------------------------
bq. are we talking about synchronization in the allocation, so only 1 thread
writes the size and end
Right. Otherwise we can have a mutation that has been fsynced, that we can't
actually replay because an earlier mutation didn't finish before the fsync.
OTOH I think this is a non-problem for Batch mode, and maybe we can wave it
away for Periodic as "you should use Batch if you care."
bq. Other option is replace recycle with discard
That's basically what mfiguiere was saying about zeroing out recycled segments.
(Probably still more efficient than creating new ones.)
> 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)
