[ 
https://issues.apache.org/jira/browse/CASSANDRA-9130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14615585#comment-14615585
 ] 

Jeff Jirsa commented on CASSANDRA-9130:
---------------------------------------

This is also discussed in CASSANDRA-9644, but quoting [~krummas] from 
CASSANDRA-9666 (which, full disclosure, is my ticket about how I'd like to 
replace DTCS with an alternative that doesn't need max_sstable_age_days at all):

{quote}
- make it possible to put a cap on the size of the windows
{quote}

The problem is that windows grow larger as they get older (increasing the cost 
of re-compaction). If max_sstable_age_days is set low, and  fragmentation 
happens - and it will happen, sooner or later, to any real production cluster - 
the alternatives are either raise max_sstable_age_days to allow compaction, or 
eat the performance/memory hit from having tens of thousands of sstables (in 
2.1.5/6, this was a near-instant OOM/crash). When you raise 
max_sstable_age_days, you'll PROBABLY run your server out of disk, because it's 
going to pick the biggest sstables and recompact them in parallel, doubling 
your usage as if you were doing an STCS major.  Yea, we all know that the 
recommendation in STCS days was to stay below 50% disk capacity, but reaching 
that limit is about the time you'll start streaming, and that's when all hell 
will break loose with DTCS as it exists. 

> reduct default dtcs max_sstable_age
> -----------------------------------
>
>                 Key: CASSANDRA-9130
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9130
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Jonathan Ellis
>            Assignee: Marcus Eriksson
>            Priority: Minor
>             Fix For: 3.x, 2.1.x, 2.0.x
>
>
> Now that CASSANDRA-9056 is fixed it should be safe to reduce the default age 
> and increase performance correspondingly.  [~jshook] suggests that two weeks 
> may be appropriate, or we could make it dynamic based on gcgs (since that's 
> the window past which we should expect repair to not introduce fragmentation 
> anymore).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to