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, 28 Nov 2013 19:44:38 GMT


Benedict commented on CASSANDRA-3578:

bq. I dunno, and I realize my OCD is showing, but Allocation isn't actually allocating anything;
it's really more of a reservation. Whereas creating a new segment actually is allocating a
Well, I'm sanguine about this, and since I had OCD for realz when I was younger, that probably
means it doesn't matter too much :-)    We could go crazy, and call neither an allocation
- a LogRecordReservation, and SegmentManagement. Although it really depends how you define
allocate - the dictionary definition definitely supports using it in either context. Just
because we allocated the system resources earlier, doesn't mean we aren't also allocating
them now, to specific use cases. I've already typed more on this than is sensible, so I'll
let you decide!

bq. How can we find out?
Experimentation, and checking the byte-code (or cludgily checking performance of an isolated
run of each approach - it'll be a noticeable difference), and hoping they don't change the
behaviour in future releases. There is literally no documentation on escape analysis, which
frustrates me no end, given that it's correct deployment probably has one of the largest performance
implications on critical code paths. I'm pretty confident it *does* backtrack object allocation
outside of some methods, but the extent to which it is willing to do so, and what behaviour
of the inner method might prevent it, is not clear.

bq. 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.
Sure, either works. If we make it explicit, then I think depending on how you define "no data
loss of more than Xms" we meet the criteria with this patch: a sync() happens at least once
every Xms; if (X+10)ms after starting it has either failed or blocked indefinitely any CL.add()
from that point will block until it succeeds, preventing the writes from being acknowledged.
So we guarantee that at most (2X+10)ms of *acknowledged* writes can be lost.

Obviously, this isn't strictly no data loss beyond that interval, because there could be lots
of blocked writes that will all also be lost, that could stack up for hours or days if they
don't spot the problem. But we won't acknowledge any of them, and I think we'd need herds
of ponies to save them.

On that topic, I just noticed a pretty glaring bug though. The first lastAliveAt assignment
in CLE should go at the very end of the try block, else on exceptions we'll continue to acknowledge
when we haven't written anything, in which case we really aren't providing those guarantees
at all. Whoops :-/

> 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