Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAKkk8iGzK9viEEOtkrpSvRzFOoyzNYjayNHEbzJVuK_HfOFFVQ@mail.gmail.com>
References: 
 <CAKkk8iGzK9viEEOtkrpSvRzFOoyzNYjayNHEbzJVuK_HfOFFVQ@mail.gmail.com>
Date: Tue, 27 Oct 2015 16:57:23 -0500
Message-ID: 
 <CAKmMYa8-pr5jDmdAB0gCJ0C6Fsnd8RCiAGrsmELBnRxR3qH0VQ@mail.gmail.com>
Subject: Re: memtable flush size with LCS
From: Nate McCall <nate@thelastpickle.com>
To: Cassandra Users <user@cassandra.apache.org>
Content-Type: multipart/alternative; boundary=001a11c1bb24af87e805231d29d7

--001a11c1bb24af87e805231d29d7
Content-Type: text/plain; charset=UTF-8

The sstable_size_in_mb can be thought of a target for the compaction
process moving the file beyond L0.

Note: If there are more than 32 SSTables in L0, it will switch over to
doing STCS for L0 (you can disable this behavior by passing
-Dcassandra.disable_stcs_in_l0=true as a system property).

With a lot of overwrites, the settings you want to tune will be
gc_grace_seconds in combination with tombstone_threhsold,
tombstone_compaction_interval and maybe unchecked_tombstone_compaction
(there are different opinions about this last one, YMMV). Making these more
aggressive and increasing your sstable_size_in_mb will allow for
potentially capturing more overwrites in a level which will lead to less
fragmentation. However, making the size too large will keep compaction from
triggering on further out levels which can then exacerbate problems
particulary if you have long-lived TTLs.

In general, it is very workload specific, but monitoring the histogram for
the number of ssables used in a read (via
org.apache.cassandra.metrics.ColumnFamily.$KEYSPACE.$TABLE.SSTablesPerReadHistogram.95percentile
or shown manually in nodetool cfhistograms output) after any change will
help you narrow in a good setting.

See
http://docs.datastax.com/en/cql/3.1/cql/cql_reference/compactSubprop.html?scroll=compactSubprop__compactionSubpropertiesLCS
for more details.

On Tue, Oct 27, 2015 at 3:42 PM, Dan Kinder <dkinder@turnitin.com> wrote:
>
> Hi all,
>
> The docs indicate that memtables are triggered to flush when data in the
commitlog is expiring or based on memtable_flush_period_in_ms.
>
> But LCS has a specified sstable size; when using LCS are memtables
flushed when they hit the desired sstable size (default 160MB) or could L0
sstables be much larger than that?
>
> Wondering because I have an overwrite workload where larger memtables
would be helpful, and if I need to increase my LCS sstable size in order to
allow for that.
>
> -dan


--
-----------------
Nate McCall
Austin, TX
@zznate

Co-Founder & Sr. Technical Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

--001a11c1bb24af87e805231d29d7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The sstable_size_in_mb can be thought of a target for the =
compaction process moving the file beyond L0. <br><br>Note: If there are mo=
re than 32 SSTables in L0, it will switch over to doing STCS for L0 (you ca=
n disable this behavior by passing -Dcassandra.disable_stcs_in_l0=3Dtrue as=
 a system property).<br><br>With a lot of overwrites, the settings you want=
 to tune will be gc_grace_seconds in combination with tombstone_threhsold, =
tombstone_compaction_interval and maybe unchecked_tombstone_compaction (the=
re are different opinions about this last one, YMMV). Making these more agg=
ressive and increasing your sstable_size_in_mb will allow for potentially c=
apturing more overwrites in a level which will lead to less fragmentation. =
However, making the size too large will keep compaction from triggering on =
further out levels which can then exacerbate problems particulary if you ha=
ve long-lived TTLs. <br><br>In general, it is very workload specific, but m=
onitoring the histogram for the number of ssables used in a read (via org.a=
pache.cassandra.metrics.ColumnFamily.$KEYSPACE.$TABLE.SSTablesPerReadHistog=
ram.95percentile or shown manually in nodetool cfhistograms output) after a=
ny change will help you narrow in a good setting. <br><br>See <a href=3D"ht=
tp://docs.datastax.com/en/cql/3.1/cql/cql_reference/compactSubprop.html?scr=
oll=3DcompactSubprop__compactionSubpropertiesLCS">http://docs.datastax.com/=
en/cql/3.1/cql/cql_reference/compactSubprop.html?scroll=3DcompactSubprop__c=
ompactionSubpropertiesLCS</a> for more details. <br><br>On Tue, Oct 27, 201=
5 at 3:42 PM, Dan Kinder &lt;<a href=3D"mailto:dkinder@turnitin.com">dkinde=
r@turnitin.com</a>&gt; wrote:<br>&gt;<br>&gt; Hi all,<br>&gt;<br>&gt; The d=
ocs indicate that memtables are triggered to flush when data in the commitl=
og is expiring or based on memtable_flush_period_in_ms.<br>&gt;<br>&gt; But=
 LCS has a specified sstable size; when using LCS are memtables flushed whe=
n they hit the desired sstable size (default 160MB) or could L0 sstables be=
 much larger than that?<br>&gt;<br>&gt; Wondering because I have an overwri=
te workload where larger memtables would be helpful, and if I need to incre=
ase my LCS sstable size in order to allow for that.<br>&gt;<br>&gt; -dan<br=
><br><br><br><br>--<br>-----------------<br>Nate McCall<br>Austin, TX<br>@z=
znate<br><br>Co-Founder &amp; Sr. Technical Consultant<br>Apache Cassandra =
Consulting<br><a href=3D"http://www.thelastpickle.com">http://www.thelastpi=
ckle.com</a></div>

--001a11c1bb24af87e805231d29d7--