[
https://issues.apache.org/jira/browse/CASSANDRA-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13835049#comment-13835049
]
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 resource.
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: https://issues.apache.org/jira/browse/CASSANDRA-3578
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Assignee: Benedict
> Priority: Minor
> Labels: performance
> Attachments: 0001-CASSANDRA-3578.patch, ComitlogStress.java,
> 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
(v6.1#6144)
