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 Sun, 01 Dec 2013 14:20:36 GMT


Jonathan Ellis commented on CASSANDRA-3578:

bq. It is non-blocking in its abstraction which makes it absolutely the correct abstraction
to use here

How is WaitQueue different from using Object.wait/notifyAll?

bq. If we were now to split out the CL.add() into the calling thread instead of the write
stage, returning a Future to wait on in the write stage, we could support max_connection writes
instead, which would be much larger

Well, in the general case of writing to more than just a single local replica, this distinction
isn't really meaningful.  At *some* point you have to do blocking i/o to disk so whether you
call that {{concurrent_writes}} or {{fake_aio_threads}} doesn't really matter.

> 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