[
https://issues.apache.org/jira/browse/CASSANDRA-6809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14103680#comment-14103680
]
Jason Brown commented on CASSANDRA-6809:
----------------------------------------
bq. I think you're still thinking in 2.0 terms
True, I haven't caught up with the CL changes for 2.1, but in my defense, I
need to ship something ASAP on 2.0 :). Will do my homework on 2.1.
bq. I'm not convinced this will behave any differently performance-wise
Yeah, me neither. Perhaps my meandering prose didn't express that I think we
can retire the pre-allocate with the segment recycle.
bq. mmap
We can still use mmap with OutputStream, in fact I've done it already on my
local hacking. However, we should evaluate if we want the mmap functionality. I
haven't thought enough about it to have a strong opinion. Either way, you still
go through the page cache, which is the part I'd like to avoid.
bq. If you mean to start using async IO in Java ...
Nope, at least, not here :)
> Compressed Commit Log
> ---------------------
>
> Key: CASSANDRA-6809
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6809
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Benedict
> Assignee: Branimir Lambov
> Priority: Minor
> Labels: performance
> Fix For: 3.0
>
>
> It seems an unnecessary oversight that we don't compress the commit log.
> Doing so should improve throughput, but some care will need to be taken to
> ensure we use as much of a segment as possible. I propose decoupling the
> writing of the records from the segments. Basically write into a (queue of)
> DirectByteBuffer, and have the sync thread compress, say, ~64K chunks every X
> MB written to the CL (where X is ordinarily CLS size), and then pack as many
> of the compressed chunks into a CLS as possible.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
