Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 1 Dec 2014 07:13:13 +0000 (UTC)
From: "Jonathan Ellis (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12757518.1416864524000.46868.1417417993212@Atlassian.JIRA>
In-Reply-To: <JIRA.12757518.1416864524000@Atlassian.JIRA>
References: <JIRA.12757518.1416864524000@Atlassian.JIRA>
 <JIRA.12757518.1416864524887@arcas>
Subject: [jira] [Commented] (CASSANDRA-8371) DateTieredCompactionStrategy is
 always compacting
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CASSANDRA-8371?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D=
14229481#comment-14229481 ]=20

Jonathan Ellis commented on CASSANDRA-8371:
-------------------------------------------

bq. Could we make it a string, and allow suffixes 'hours', 'days', 'weeks',=
 'years', but just assume 'days' if not specified?

Not really a fan since we named the option _days already. :-|

> DateTieredCompactionStrategy is always compacting=20
> --------------------------------------------------
>
>                 Key: CASSANDRA-8371
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8371
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: mck
>            Assignee: Bj=C3=B6rn Hegerfors
>              Labels: compaction, performance
>         Attachments: java_gc_counts_rate-month.png, read-latency-recommen=
ders-adview.png, read-latency.png, sstables-recommenders-adviews.png, sstab=
les.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 incre=
ase, along with the number of reads happening in the "compaction" hump of c=
fhistograms.
> Data, and generally performance, looks good, but compactions are always h=
appening, and pending compactions are building up.
> The schema for this is=20
> {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 (wee=
k ~44), to DTCS (week ~46).
> These screenshots are also found in the prezi on slides 9-11.
> [~pmcfadin], [~Bj0rn],=20
> Can this be a consequence of occasional deleted rows, as is described und=
er (3) in the description of CASSANDRA-6602 ?


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