[
https://issues.apache.org/jira/browse/CASSANDRA-6809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14103210#comment-14103210
]
Benedict commented on CASSANDRA-6809:
-------------------------------------
It's also potentially less capable of utilising machines with small numbers of
high performance disks (i.e. compression is generally slower than many SSDs can
now write), so it may not be future proof, and won't utilise all of our users'
hardware maximally, but I doubt that will be a major issue for the moment and
it should at least improve the current situation.
If we're comfortable with that, and with dropping CLS recycling (which I am, I
was never really convinced it was worth the effort) we can simplify things
quite a lot. So I'm cool with that approach.
We'll want to limit the concurrency in this case, however, to e.g. 25% of num
CPUs (so we're only 50% of physical cores on HT CPUs), as occupying every CPU
with compressing/encrypting large blocks of data will result in potentially
large latency spikes.
> 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)
