[jira] [Issue Comment Deleted] (CASSANDRA-8371) DateTieredCompactionStrategy is always compacting

["mck (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-8371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

mck updated CASSANDRA-8371:
---------------------------
    Comment: was deleted

(was: > Björn Hegerfors thanks. i'll take a look into getting those diagnostics hopefully next week.

Apologises for not following up on this!

We've been using DTCS on another table happily all this time.
And the original table this issue was reported against remains back on LCS.
And we're still running 2.0.11

We have other tables that would be a better fit (with the default options) on DTCS and would like to switch over before experimenting any more with that original table which seems quite happy with LCS. Playing around with the options aganst brand new features in C* I've been burnt with before, so the plan is to focus on operational experience on default settings to begin with.

I knew when I entered this issue that the deletes were going against what DTCS is to be used on (although there turned out to be surprisingly many more deletes than i knew about), and that entering the issue could at least help others making the same mistake to quickly identify their fault. Instead arose a healthy discussion on other aspects around DCTS, educational in itself, but for my part i'd be happy to close the issue, and let those discussions continue in new issues created.
)

> DateTieredCompactionStrategy is always compacting 
> --------------------------------------------------
>
>                 Key: CASSANDRA-8371
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8371
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: mck
>            Assignee: Björn Hegerfors
>              Labels: compaction, performance
>         Attachments: java_gc_counts_rate-month.png, read-latency-recommenders-adview.png, read-latency.png, sstables-recommenders-adviews.png, sstables.png, vg2_iad-month.png
>
>
> Running 2.0.11 and having switched a table to [DTCS|https://issues.apache.org/jira/browse/CASSANDRA-6602] we've seen that disk IO and gc count increase, along with the number of reads happening in the "compaction" hump of cfhistograms.
> Data, and generally performance, looks good, but compactions are always happening, and pending compactions are building up.
> The schema for this is 
> {code}CREATE TABLE search (
>   loginid text,
>   searchid timeuuid,
>   description text,
>   searchkey text,
>   searchurl text,
>   PRIMARY KEY ((loginid), searchid)
> );{code}
> We're sitting on about 82G (per replica) across 6 nodes in 4 DCs.
> CQL executed against this keyspace, and traffic patterns, can be seen in slides 7+8 of https://prezi.com/b9-aj6p2esft/
> Attached are sstables-per-read and read-latency graphs from cfhistograms, and screenshots of our munin graphs as we have gone from STCS, to LCS (week ~44), to DTCS (week ~46).
> These screenshots are also found in the prezi on slides 9-11.
> [~pmcfadin], [~Bj0rn], 
> Can this be a consequence of occasional deleted rows, as is described under (3) in the description of CASSANDRA-6602 ?



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