cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Shook (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9130) reduct default dtcs max_sstable_age
Date Mon, 06 Jul 2015 20:05:04 GMT

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

Jonathan Shook commented on CASSANDRA-9130:
-------------------------------------------

I'm not particularly concerned about the corner cases for lots of sstables, but it does need
to be documented better. We do not yet have tools to manage re-compacting DTCS past max_sstable_age_days.
Even if we did, it would not be an automatic win in every case. The operational trade-offs
that come with different max_sstable_age_days are simply too stark to avoid. I still believe
that 365 is way too high. Studying the total bytes compacted over different DTCS settings
and ingest rates can show the IO load. 365 is way beyond the point at which you start paying
for more compaction than you need in most systems.

I do agree, though about the boundary condition. We should have a safety in place to avoid
max_sstable_age_days > table TTL until we can verify that a TTL-specific compaction pass
will occur as needed.
This might be a concern as well for per-write TTLs.

[~jjirsa]
Is there a way that you would like to see the interplay between TTLs and max_sstable_age_days
handled? Is there a solution which you would consider safe?




> 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)

Mime
View raw message