[
https://issues.apache.org/jira/browse/CASSANDRA-8771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14313701#comment-14313701
]
Jason Brown commented on CASSANDRA-8771:
----------------------------------------
I'll admit I like the idea that we're being more resource conservative vis a
vis recycling, yet I have no measurements to prove we actually are. The code is
complex for what we all suspect is limited payoff, so I I'm 90% in favor of
killing it, as well. The last bit of me wants to see that removing the
recycling makes no substantive performance changes for the worse - however, it
could be argued that those performance number should have been submitted when
the recycling was first introduced.
TL;DR - dump it
> Remove commit log segment recycling
> -----------------------------------
>
> Key: CASSANDRA-8771
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8771
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Ariel Weisberg
>
> For discussion
> Commit log segment recycling introduces a lot of complexity in the existing
> code.
> CASSANDRA-8729 is a side effect of commit log segment recycling and
> addressing it will require memory management code and thread coordination for
> memory that the filesystem will no longer handle for us.
> There is some discussion about what storage configurations actually benefit
> from preallocated files. Fast random access devices like SSDs, or
> non-volatile write caches etc. make the distinction not that great.
> I haven't measured any difference in throughput for bulk appending vs
> overwriting although it was pointed out that I didn't test with concurrent IO
> streams.
> What would it take to make removing commit log segment recycling acceptable?
> Maybe a benchmark on a spinning disk that measures the performance impact of
> preallocation when there are other IO streams?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
