cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3578) Multithreaded commitlog
Date Thu, 07 Nov 2013 14:07:23 GMT


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

View raw message