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 19:55:18 GMT


Benedict commented on CASSANDRA-3578:

bq. I am talking about count all the allocation and written, within a segment.... Which is
(A + B + C) != (A + B) (which means C or someone else is still writing).

but this gets updated as you're reading, so unless you read allocationPosition = writtenPosition
= allocationPosition you can fail - and so you need to spin until you see this three way check
succeed, which I'm not keen on. Since they are both being updated all the time, this could
potentially mean a lengthy period of spinning.

bq. Thats fine we will skip those, thats what the current implementation does too

The current implementation never ACKs a message it cannot later replay under batch, but this
approach would permit that to happen.

> 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