cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Litsche <>
Subject Re: How to avoid flush if the data can fit into memtable
Date Thu, 01 Jun 2017 14:04:30 GMT
Hello Akhil,

thanks for your great blog post.
One thing I cannot bring together:
In the answer mail you write:
"Note the cleanup threshold is .50 of 1GB and not a combination of heap and
off heap space."
In your blog post you write:
"memtable_cleanup_threshold is the default value i.e. 33 percent of the
total memtable heap and off heap memory."

Could you clarify this?


2017-05-30 2:43 GMT+02:00 Akhil Mehra <>:

> Hi Preetika,
> After thinking about your scenario I believe your small SSTable size might
> be due to data compression. By default, all tables enable SSTable
> compression.
> Let go through your scenario. Let's say you have allocated 4GB to your
> Cassandra node. Your *memtable_heap_space_in_mb* and
> *memtable_offheap_space_in_mb  *will roughly come to around 1GB. Since
> you have memtable_cleanup_threshold to .50 table cleanup will be
> triggered when total allocated memtable space exceeds 1/2GB. Note the
> cleanup threshold is .50 of 1GB and not a combination of heap and off heap
> space. This memtable allocation size is the total amount available for all
> tables on your node. This includes all system related keyspaces. The
> cleanup process will write the largest memtable to disk.
> For your case, I am assuming that you are on a *single node with only one
> table with insert activity*. I do not think the commit log will trigger a
> flush in this circumstance as by default the commit log has 8192 MB of
> space unless the commit log is placed on a very small disk.
> I am assuming your table on disk is smaller than 500MB because of
> compression. You can disable compression on your table and see if this
> helps get the desired size.
> I have written up a blog post explaining memtable flushing (
> Let me know if you have any other question.
> I hope this helps.
> Regards,
> Akhil Mehra
> On Fri, May 26, 2017 at 6:58 AM, preetika tyagi <>
> wrote:
>> I agree that for such a small data, Cassandra is obviously not needed.
>> However, this is purely an experimental setup by using which I'm trying to
>> understand how and exactly when memtable flush is triggered. As I mentioned
>> in my post, I read the documentation and tweaked the parameters accordingly
>> so that I never hit memtable flush but it is still doing that. As far the
>> the setup is concerned, I'm just using 1 node and running Cassandra using
>> "cassandra -R" option and then running some queries to insert some dummy
>> data.
>> I use the schema from CASSANDRA_HOME/tools/cqlstress-insanity-example.yaml
>> and add "durable_writes=false" in the keyspace_definition.
>> @Daemeon - The previous post lead to this post but since I was unaware of
>> memtable flush and I assumed memtable flush wasn't happening, the previous
>> post was about something else (throughput/latency etc.). This post is
>> explicitly about exactly when memtable is being dumped to the disk. Didn't
>> want to confuse two different goals that's why posted a new one.
>> On Thu, May 25, 2017 at 10:38 AM, Avi Kivity <> wrote:
>>> It doesn't have to fit in memory. If your key distribution has strong
>>> temporal locality, then a larger memtable that can coalesce overwrites
>>> greatly reduces the disk I/O load for the memtable flush and subsequent
>>> compactions. Of course, I have no idea if the is what the OP had in mind.
>>> On 05/25/2017 07:14 PM, Jonathan Haddad wrote:
>>> Sorry for the confusion.  That was for the OP.  I wrote it quickly right
>>> after waking up.
>>> What I'm asking is why does the OP want to keep his data in the memtable
>>> exclusively?  If the goal is to "make reads fast", then just turn on row
>>> caching.
>>> If there's so little data that it fits in memory (300MB), and there
>>> aren't going to be any writes past the initial small dataset, why use
>>> Cassandra?  It sounds like the wrong tool for this job.  Sounds like
>>> something that could easily be stored in S3 and loaded in memory when the
>>> app is fired up.
>>> On Thu, May 25, 2017 at 8:06 AM Avi Kivity <> wrote:
>>>> Not sure whether you're asking me or the original poster, but the more
>>>> times data gets overwritten in a memtable, the less it has to be compacted
>>>> later on (and even without overwrites, larger memtables result in less
>>>> compaction).
>>>> On 05/25/2017 05:59 PM, Jonathan Haddad wrote:
>>>> Why do you think keeping your data in the memtable is a what you need
>>>> to do?
>>>> On Thu, May 25, 2017 at 7:16 AM Avi Kivity <> wrote:
>>>>> Then it doesn't have to (it still may, for other reasons).
>>>>> On 05/25/2017 05:11 PM, preetika tyagi wrote:
>>>>> What if the commit log is disabled?
>>>>> On May 25, 2017 4:31 AM, "Avi Kivity" <> wrote:
>>>>>> Cassandra has to flush the memtable occasionally, or the commit log
>>>>>> grows without bounds.
>>>>>> On 05/25/2017 03:42 AM, preetika tyagi wrote:
>>>>>> Hi,
>>>>>> I'm running Cassandra with a very small dataset so that the data
>>>>>> exist on memtable only. Below are my configurations:
>>>>>> In jvm.options:
>>>>>> -Xms4G
>>>>>> -Xmx4G
>>>>>> In cassandra.yaml,
>>>>>> memtable_cleanup_threshold: 0.50
>>>>>> memtable_allocation_type: heap_buffers
>>>>>> As per the documentation in cassandra.yaml, the
>>>>>> *memtable_heap_space_in_mb* and *memtable_heap_space_in_mb* will
>>>>>> set of 1/4 of heap size i.e. 1000MB
>>>>>> According to the documentation here (
>>>>>> assandra/3.0/cassandra/configuration/
>>>>>> ml#configCassandra_yaml__memtable_cleanup_threshold), the memtable
>>>>>> flush will trigger if the total size of memtabl(s) goes beyond
>>>>>> (1000+1000)*0.50=1000MB.
>>>>>> Now if I perform several write requests which results in almost
>>>>>> ~300MB of the data, memtable still gets flushed since I see sstables
>>>>>> created on file system (Data.db etc.) and I don't understand why.
>>>>>> Could anyone explain this behavior and point out if I'm missing
>>>>>> something here?
>>>>>> Thanks,
>>>>>> Preetika

Stefan Litsche | Mobile: +49 176 12759436 E-Mail:

View raw message