[
https://issues.apache.org/jira/browse/CASSANDRA-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815977#comment-13815977
]
Benedict commented on CASSANDRA-3578:
-------------------------------------
If we do neither (2) or my previous approach of linearizing the writes and only
marking complete up until the furthest contiguously written point then, at the
very least, our batch executor could ACK a commit that may be unreadable on
replay because earlier log messages haven't been written (without their sizes
being synced we can't read the later messages). Don't need a poweroff scenario,
just a kill would do.
For Periodic sync we probably don't care so much, although there's no guarantee
how long a thread could have been paused for. Should be micros, but we could
theoretically have multiple flushes unreadable due to a stalled / failed log
write.
> 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)
