cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3578) Multithreaded commitlog
Date Thu, 28 Nov 2013 16:11:38 GMT


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:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Jonathan Ellis
>            Assignee: Benedict
>            Priority: Minor
>              Labels: performance
>         Attachments: 0001-CASSANDRA-3578.patch,, 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

View raw message