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, 05 Dec 2013 19:39:36 GMT


Benedict commented on CASSANDRA-3578:

The idea of the % was to give some sense of scale of the problem. The problem with just offering
a count is that it's only averaged over the number of lagged commits, which doesn't tell the
whole story (if most of the commits didn't lag, it might not be worth worrying about), and
averaging over all the commits might be overly dismissive because a lot of commits may be
NO-OPs, so giving a ratio of time spent committing to time spent lagged seemed a useful compromise.
Though perhaps simply total time spent lagged and total time spent committing might be more

> Multithreaded commitlog
> -----------------------
>                 Key: CASSANDRA-3578
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Jonathan Ellis
>            Assignee: Benedict
>            Priority: Minor
>              Labels: performance
>             Fix For: 2.1
>         Attachments: 0001-CASSANDRA-3578.patch, 3578-logging-v2.txt,,
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