org"
>> Date: Wednesday, October 28, 2015 at 11:45 AM
>> To: Cassandra Users
>> Subject: Re: memtable flush size with LCS
>>
>>
>> do you mean that this property is ignored at memtable flush time, and so
>>> memtables are already allowed to be much larg
uot;user@cassandra.apache.org"
> Date: Wednesday, October 28, 2015 at 11:45 AM
> To: Cassandra Users
> Subject: Re: memtable flush size with LCS
>
>
> do you mean that this property is ignored at memtable flush time, and so
>> memtables are already allowed to be mu
e.org"
Date: Wednesday, October 28, 2015 at 11:45 AM
To: Cassandra Users
Subject: Re: memtable flush size with LCS
do you mean that this property is ignored at memtable flush time, and so
memtables are already allowed to be much larger than sstable_size_in_mb?
Yes, 'sstable_size_
> do you mean that this property is ignored at memtable flush time, and so
> memtables are already allowed to be much larger than sstable_size_in_mb?
>
Yes, 'sstable_size_in_mb' plays no part in the flush process. Flushing is
based on solely on runtime activity and the file size is determined by
Thanks, I am using most of the suggested parameters to tune compactions. To
clarify, when you say "The sstable_size_in_mb can be thought of a target
for the compaction process moving the file beyond L0." do you mean that
this property is ignored at memtable flush time, and so memtables are
already
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).
Wit
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
