[
https://issues.apache.org/jira/browse/CASSANDRA-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13834948#comment-13834948
]
Jonathan Ellis commented on CASSANDRA-3578:
-------------------------------------------
bq. We provide this guarantee just as well as we used to
I get that, I'm just asking if we can improve on that. :)
bq. I think perhaps a better scheme is to attempt to sync() twice every "poll
interval"
Dunno, if we're going to do that let's just make more explicit what our
guarantees are and let them half the interval themselves if that's what they
want.
bq. It's likely that it will find the allocations don't escape, but I'm not
sure how well it handles back-tracking out of the allocating method to do so.
How can we find out?
> 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, 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)
