cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] Updated: (CASSANDRA-622) Improve commitlog performance
Date Wed, 10 Mar 2010 20:02:27 GMT


Jonathan Ellis updated CASSANDRA-622:

     Labels: gsoc  (was: )
    Summary: Improve commitlog performance  (was: better commitlog performance)

Brian Aker adds that allowing multiple threads to modify the commitlog simultaneously (reserving
space for each with a CAS first) can also improve performance.  Presumably mmap-ing the commitlog
segment is required for this [another thing that fixed-length segments would allow].

(CAS isn't part of the jdk spec but it is available for public use in the sun jars.  Cliff
Click's high-scale-lib uses it extensively, so using it wouldn't be a new dependency for us.) describes the current CommitLog design.

> Improve commitlog performance
> -----------------------------
>                 Key: CASSANDRA-622
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Jonathan Ellis
>            Priority: Minor
> Postgresql uses fixed-size commitlog files that it pre-allocates (filling with zeros)
so "appending" to the log can use cheaper fsync-without-metadata (length changes is "metadata").
 Then, when a commitlog is not needed, it "recycles" it by renaming it to a higher number.
 Commitlog entries have an increasing id, and if you come to an out-of-sequence (earlier)
id, then you must have have reached the end of the commitlog and are reading from the "recycled"

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message