[
https://issues.apache.org/jira/browse/CASSANDRA-6809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14313299#comment-14313299
]
Ariel Weisberg commented on CASSANDRA-6809:
-------------------------------------------
* In cassandra.yaml, for commitlog_compression_threads can you document that
the default is 1?
* Cap the size of the buffer pool to a fixed number of buffers. If you end up
allocating more than that number, free the memory rather then pooling.
* awaitTermination changed from block forever to block for 3600 seconds. I have
never been a fan of ExecutorService's async termination. If it was supposed to
finish it's last task it should terminate and if it doesn't then something is
wrong.
* I’d still like to see the JSON field in commit log descriptor be reusable for
other config parameters.
* In CommitLogSegment constructor it is no longer truncating the file, why is
it no longer necessary?
I am more comfortable with the single threaded task generation in Benedict's
diff. I would rather see that or no multi-threading for now.
> 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
>
> Attachments: ComitLogStress.java, logtest.txt
>
>
> 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.3.4#6332)
